Release 0.9.0

[hakonanes]

Due to recent improvements to the code base by @harripj, we've decided to make a 0.9 release. The improvements break the API, to the point where many of kikuchipy's tests fail (in a straightforward way), so it would be good to get them released and tested by users and in downstream packages before releasing 1.0 🚀

To include in 0.9 (add or remove as you see fit):

• Deprecated functionality to be removed in v0.9 #229
• Consider the use of unique for identical symmetries in Orientation.dot #296
• Possible regression in 0.8.1 for orientation clustering #297
• Add Symmetry plot method #306
• Reproject hidden part of circle about vector to current hemisphere #308
• Speed up dot and dot_outer by not calling unique for identical Symmetry #303
• Directionality in Euler methods #294
• Remove orix.scalar and Scalar class #301
• Add Orientation.angle_with_outer() which is based on get_distance_matrix() #302
• Silence warnings when convention argument is not passed #304
• Add equality operator to Rotation and hash to Symmetry #305
• Add Vector3d.scatter() reproject onto hemisphere functionality #307
• Add logo to README.rst #310
• Fix writing property arrays in masked CrystalMap to .ang file #312
• Add Dask-based lazy computation of quaternion-vector outer product #321

I propose to make a release candidate (rc) 0.9.0rc1 on PyPI (I think conda-forge is unnecessary) so that kikuchipy can be updated to work with the coming 0.9.0. I can handle these releases unless someone else wants to.

Apart from the benfit of having some time between 0.9 and 1.0, there is no particular rush to get this out, at least not from my end.

Input on this plan is as always welcome!

[harripj]

I think a 0.9 release is a good idea for the reasons you mentioned @hakonanes.

Regarding the changes #296 and #298 I think are improvements and additions which do should not break anything. #295 may require some minor reworking to existing code to avoid memoryviews popping up everywhere. #294 however may change existing code and should be checked thoroughly on affected code, as discussed in the PR.

I agree that there is not necessarily a rush to package this up, and that we should give some time after this release for other projects to adopt the changes and catch up.

[pc494]

I propose to make a release candidate (rc) 0.9.0rc1 on PyPI (I think conda-forge is unnecessary)

I agree with a release candidate, and iirc conda-forge don't accept release candidates anyway.

[harripj]

I think we're getting pretty close to finishing this up, after #303 and #308 are reviewed and merged. #296 will be closed by #303. @hakonanes will you look further into #297? It doesn't seem to be a big issue as discussed in that PR. Finally a bit of tidying up with #229.

[hakonanes]

I'll do the tasks in #297, and also try to find a way to include the misorientation clustering notebook in the Read the Docs documentation. We can then archive the orix-demos repo 🎉

[pc494]

Ah also! After this is out the door we should move from master to main (unless we've already discussed this)

[hakonanes]

There are no outstanding issues as far as I can tell. I'm happy with releasing 0.9 tomorrow if people are OK with this.

[harripj]

Sounds like a good idea to me!

Ah also! After this is out the door we should move from master to main (unless we've already discussed this)

This also.

[hakonanes]

I meant a 0.9rc1 release candidate, so that any issues removing the .data property can be fixed in kikuchipy and diffsims.

[harripj]

I meant a 0.9rc1 release candidate

Also fine with this.

After the 0.9 release perhaps we also implement a develop branch as suggested in #243?

[pc494]

Happy for a rc to come out, ideally would delay a full release until after the epsic workshop (May 9th-13th) to save some people headaches.

[hakonanes]

delay a full release until after the epsic workshop (May 9th-13th)

Sure, we can plan for a release of v0.9 (not release candidate) Monday 16th!

[pc494]

delay a full release until after the epsic workshop (May 9th-13th)

Sure, we can plan for a release of v0.9 (not release candidate) Monday 16th!

That was the date I had in mind too

[hakonanes]

I'm releasing 0.9.0rc1 tomorrow before lunch.

[hakonanes]

0.9.0rc1 is now available on TestPyPI here, but not on PyPI as the newly modified publish action only uploads there if the action is triggered from a tagged release. This extra safety net is fine but not necessary in my opinion, so I suggest to remove it.

[hakonanes]

I made yet another mistake: The publish workflow exits when a step fails. 0.9.0rc1 was already on TestPyPI and so couldn't be uploaded again, which made that step fail, and the following step uploading to PyPI wasn't run. Before reading the TestPyPI docs, I deleted 0.9.0rc1 from TestPyPI in the belief that we could re-upload the same release to TestPyPI, which we cannot.

A solution is to add continue-on-error to the publish workflow so that we can upload to PyPI even though we cannot upload to TestPyPI. But, that defeats the main purpose of first uploading to TestPyPI, which is to check that everything works before uploading to PyPI.

The only other solutions I can see is either to create a new 0.9.0rc2 release or upload to PyPI locally. I think a new release is simplest.

[harripj]

I think there is no problem with bumping to an rc2 release!

[hakonanes]

Great, in this case I'll push a commit directly to master with the version bumped to 0.9.0rc2.

[hakonanes]

0.9.0rc2 is now available on PyPI. I'll set up release PRs (to be merged right after orix 0.9.0 is available) for diffsims and kikuchipy within the next few days.

[hakonanes]

v0.9.0 is available on PyPI. Waiting for the conda-forge bot to update the orix-feedstock.

The Zenodo webhook initially failed to upload v0.9.0 to Zenodo, but succeded when I triggered a redelivery. But Zenodo doesn't display the latest version yet. I'm not maintainer of that Zenodo upload, so I cannot do anything than wait for it to update. Would be good if maintainers of that upload can check. I'd like to be a maintainer of the upload as well, if possible (not sure how that works).

[hakonanes]

If Zenodo doesn't update for some reason, we can always upload v0.9.0 manually.

[pc494]

Yeah not sure what's gone on with the Zenodo, do you want me to look into it?

[hakonanes]

Yes, I would appreciate that.

[hakonanes]

0.9.0 is now available from the conda-forge channel. The only thing remaining is the Zenodo DOI, which I'd like to have updated before closing this issue.

[hakonanes]

I'm 99.9% sure Zenodo couldn't parse the metadata file because I didn't include the list of contributors in a "creators" field. I think the only solution for this release is to upload it manually. The Zenodo metadata file is fixed in #341.

[harripj]

A general question, is the upload to Zenodo is triggered automatically when a new version is released on PyPI?

[hakonanes]

No, Zenodo receives repo metadata whenever we do anything with a release (create, edit, publish, unpublish, or delete). From my understanding based on past experience, Zenodo only adds a new version when a published release is tagged.

[harripj]

Thanks for answering!

[pc494]

(@harripj for completeness)
We've hooked both PyPi and Zenodo to trigger on the tagging of a release here. This means (for example) release candidates go to both. As far as I recall conda will only trigger when pypi take a new full version.

@hakonanes
Would you be willing to consider a 0.9.1 with correct Zenodo information, it's a bit ugly, but it's how I dealt with this problem in pyxem.

[harripj]

Thanks @pc494 for the explanation!

[hakonanes]

Would you be willing to consider a 0.9.1 with correct Zenodo information

I'd prefer not to since this means more work in PRs and a conda-forge release. And, it seems like I can create the "orix 0.9.0" release myself on Zenodo, since I'm a maintainer. I didn't find this via Zenodo's account settings previously, but I did now.

[hakonanes]

As far as I recall conda will only trigger when pypi take a new full version.

This is true. But we can of course make a PR ourselves to the orix feedstock and release a release candidate on conda-forge.

[hakonanes]

And, it seems like I can create the "orix 0.9.0" release myself on Zenodo, since I'm a maintainer. I didn't find this via Zenodo's account settings previously, but I did now.

Sorry, this is not true, Zenodo just took me to GitHub for making a new release.

[hakonanes]

OK, looking at Python versioning, I think a post-release versioned 0.9.0.post0 with the fixed .zenodo.json file is what we're after.

I suggest that I:

1. Branch off of the v0.9.0 tag locally
2. Cherry pick the commit fixing .zenodo.json
3. Bump version from "0.9.0" to "0.9.0.post0"
4. Create new tag v0.9.0.post0 locally
5. Push the tag to this repo
6. Release orix 0.9.0.post0 stating the reason for this release

EDIT: To ensure all changes were recorded in the master branch, we merged the above suggested changes in a PR to master and tagged the normal way via GitHub.

[harripj]

OK, looking at Python versioning, I think a post-release versioned 0.9.0.post0 with the fixed .zenodo.json file is what we're after.

I think this sounds like a good plan.

[hakonanes]

Zenodo is now updated. I'll make a final PR to master re-bumping the version, and handle the eventual conda-forge release of 0.9.0.post0.

[pc494]

Elegant, many thanks @hakonanes