antspy to v0.5.0 and bump ants + itk versions to latest commit hashes

[ncullen93]

Bumps antspy to v0.5.0 and use the latest ants and itk commit hashes for building. We'll see if it's this simple...

Eventual general release notes:

• improved testing
• minor bug fixes
• minor documentation improvements
• upgrade to latest ANTs and ITK version
• removed deprecated code (VTK-related visualization)

Things to accomplish during v0.5.x

• rework docs and tutorials (to ants.dev)
• reduce build size
• refactor ants.plot function to be simpler
• speed up import time (by deferring imports?)

[cookpa]

This looks great, thanks @ncullen93

To avoid confusion in the future, could we reserve vX.Y.Z for tags of release commits, and use vX.Y.Z-dev or something for branch names?

[ncullen93]

That'd be great but how would it work exactly? On the main branch it will always be "X.Y.Z-dev" and then when it's time for a release we just remove the "-dev", publish the release, and then add it back?

Also - it looks like the linux action failed to publish to pypi when you merged because the package size was too large... so I'm not sure if it has been updated on pypi?

Edit - looks like it's not the specific build size but just the total storage on pypi being over 10gb? So some old wheels need to be deleted? For what it's worth, I really don't think you need to build wheels for each python distribution specifically. I think it's more common to just build one wheel for "3.x" - see e.g., the pypi workflow I use elsewhere.

[cookpa]

That'd be great but how would it work exactly? On the main branch it will always be "X.Y.Z-dev" and then when it's time for a release we just remove the "-dev", publish the release, and then add it back?

I was thinking we'd make a vX.Y.Z-dev branch, and push commits to it until we're ready, then merge back into main, tag HEAD with vX.Y.Z, and then hit release.

[gdevenyi]

Here's the ref for the official way to name development releases in Python https://peps.python.org/pep-0440/#development-release-separators

[cookpa]

Open to changing things to be more pythonic, but what I was trying to suggest here is that we avoid having a branch and a tag with the same label. It's technically allowed by Git but I am easily confused

[ntustison]

@ncullen93 @cookpa --- how should we update this with respect to the recent KK change?

[cookpa]

I think a bug fix release would be in order

[ncullen93]

I'm fine with whatever but I prefer making changes on the main branch. People probably expect the main branch to be the most up-to-date version of the code. Then making the version in setup.py / the actual package "vX.Y.Z-dev" would make sense.

[cookpa]

Agreed 100%, making PRs and then merging to master incrementally is the way to go. The release branches should just be like this PR, for doing release finalization. I just don't want to confuse the tag v0.5.0 on the master branch, with the v0.5.0 branch itself. But if we clean up the release PR branches as we go, then I suppose the risk is pretty minimal. I'm going to delete the branch now as the site is prompting me.

Regarding dev release numbers in the code, ITK does something like this, the code for which was adapted into ANTs, it sets the version on compile to something other than the last release tag, so we can tell if someone is using the actual tag commit or some commit between tags. This only works correctly if built from a cloned git repo, because it uses git to figure out the commit it's being built from. Might be nice to have - but we need to have a sensible fallback (eg, to the hard-coded previous release tag).