Release 0.1.15

[oesteban]

We could've released it long ago, as a fair amount of features have been included. Let's exercise the release process with the current status.

[esavary]

I've drafted the release here. Should we perhaps merge #171 and #172 before releasing in order to include the fixes for the ruff and Sphinx issues? Also, a naive question: Is there a mechanism to automatically generate the binaries for the release, or is it okay if I drag and drop some generated locally?

[arokem]

I think that adding a GitHub action for generating the package and uploading it to pypi (something like this) would be beneficial.

EDIT: edited for clarity.

[esavary]

I think that adding a GitHub action for generating the package and uploading it to pypi (something like this) would be beneficial.

EDIT: edited for clarity.

It seems like a good idea. I've created a new issue about it and will start working on a PR to implement this.

[oesteban]

We normally do this with circle, paired with uploading a docker image -- in this case that doesn't seem necessary.

The other reason for doing it from circle is that we do run more tests there (we pay credits for it) and therefore, a GHA may push a new release with tests failing.

[esavary]

We normally do this with circle, paired with uploading a docker image -- in this case that doesn't seem necessary.

The other reason for doing it from circle is that we do run more tests there (we pay credits for it) and therefore, a GHA may push a new release with tests failing.

Ok thanks, I've close the issue related to this #178 . Can you provide more details on how I can use this to add the files for the release?

[esavary]

@effigies considering that #182 and #179 for the automated releases have been merged, do you think we can proceed with cutting the release?

[effigies]

Yes, please don't wait on me. LMK if you need help.

[esavary]

Yes, please don't wait on me. LMK if you need help.

I have a quick question: should I update eddymotion/CHANGES.rst before pushing the tag? The file seems to have been automatically generated during the initial release, but I'm not entirely sure how it works.

[effigies]

For a given tag ($TAG):

bash .maint/update_changes.sh $TAG
# review CHANGES.rst, make any updates for clarity, add release notes
# I generally group the entries by FIX, ENH, RF, DOC, STY, MNT, CI
git add CHANGES.rst
git commit -m "REL: $TAG"
git tag -a -F CHANGES.rst -e $TAG
# Remove ==== from second line, remove everything below the current changelog

[esavary]

For a given tag ($TAG):

bash .maint/update_changes.sh $TAG
# review CHANGES.rst, make any updates for clarity, add release notes
# I generally group the entries by FIX, ENH, RF, DOC, STY, MNT, CI
git add CHANGES.rst
git commit -m "REL: $TAG"
git tag -a -F CHANGES.rst -e $TAG
# Remove ==== from second line, remove everything below the current changelog

Thanks a lot! I've pushed the tag. It should soon trigger the GitHub action that requests reviews from maintainers before publishing the package.

[esavary]

Actually, is it mandatory for the tag to have exactly the same number as the release number? Otherwise, I'll remove my tag and push it with the number following the last tag.

[effigies]

Yes, the tag should match the release.

Also, you should push main and the tag:

git push upstream main $TAG

[effigies]

It worked! https://pypi.org/project/eddymotion/0.1.15/