Scoping issue for a 1.0 release

[pc494]

This is mainly an issue to get the lay of the land in terms of new features people either (a) want or (b) are hoping to implement in a short/medium term timeline (6 months give or take). After #201 and #235 I think @hakonanes had almost everything he had hoped for? @harripj are you working on anything with that kind of time frame?

NB: Work that is not ready to be seen in public can be sent to the pyxem email and will be treated as confidential.

[hakonanes]

I have a couple of things I'd like to get in at some point.

Entirely new:

• 151: I have a MapRegions class locally which is a nice tool to create spatial masks from enclosed regions based on some property, say particles of a certain size. These masks can be used to for example get one averaged diffraction pattern (EBSD in my case) per region. I hope to set up a PR with this class once I have a manuscript ready which uses it within... February? Not because the class is top secret, but because I'll only see which parts of it are useful after the manuscript is ready.

Better use of existing functionality:

• Pole figure plotting should be included. Currently, we have (~orientations single_crystal_direction).scatter() working, however we need to support (~orientations symmetrised_crystal_direction).scatter(), which throws an error because of shape mismatch. This should not be much work, and I can do this. I'll raise an issue at a later point: #265.

• 171: This would be very nice when deciding crystal axis alignment in #249.

• 186: This is in kikuchipy, only needs to be moved here.

• 51: This is in kikuchipy, only needs to be moved here.

Apart from this I'm quite happy with the functionality in orix for the moment.

[pc494]

Okay, this might need an actual meeting, but I feel that this release (ie. the next major/minor after 0.8.x) should be the 1.0.0 - I think this an honest reflection of the state of the code, and it communicates how substantial some of the rewrites we're now considering (#267, #270). I've retitled this issue accordingly and am keen for thoughts: @hakonanes, @harripj, @din14970

NB: apologies for the ping late on a Friday, my orix life just do be like that now.

[din14970]

As I have not directly contributed to orix in a while and have not followed all the awesome new developments I think I my opinion in this discussion is not so relevant. As for #267 and #270, they are merely some suggestions that I thought were interesting but I'm not sure if I would get around to properly implementing them. #267 should in theory be easier, #270 may require new features in ASE to be feasible, unless we support both ASE and diffpy as "backends".

What I would still like to contribute to is on improving and adding some features to diffsims. I think some refactoring there is also in order to make use of some of the new orix functionality.

[pc494]

Thanks @din14970 that sounds good to me, and I'm extremely happy to have people on board with diffsims as I think that's the least well supported of the core pyxem quartet at the moment.

[harripj]

@pc494 I also feel as though the features and code in orix are becoming more stable, especially since the 0.8 release, and a 1.0 release would be justified. As @din14970 mentioned, a diffpy/ASE backend could be created, but I don't forsee this changing the main functionality of orix. If we were to decide to properly attempt incorporating numpy-quaternion, however, my opinion is that this should be decided, coded, and tested before a 1.0 release. There likely is merit to doing this, but it would require time.

[hakonanes]

it communicates how substantial some of the rewrites we're now considering (https://github.com/pyxem/orix/issues/267, https://github.com/pyxem/orix/issues/270)

Could you clarify what you mean 1.0 would communicate? Do you mean that we should release 1.0 before potentially doing the rewrites?

---

We've used orix in kikuchipy since orix 0.4 (August 2020), and we've only made minor changes to the use of orix' core functionality like Rotation, Orientation, and Vector3d methods with new orix releases. Based on this I would say the core functionality is stable (barring bug fixes like #277). After #249 is closed, I'm OK with a 1.0 release, but I'm equally OK with continuing release 0.9, 0.10, 0.11 etc.

What do we gain by releasing a 1.0? What do we want to communicate with it? Will packages besides the pyxem packages trust the functionality more? Developers of DefDap from Manchester (https://github.com/MechMicroMan/DefDAP/issues/92#issuecomment-979346829) and PyEBSDIndex from US NRL (private communication) have expressed interest in using orix, but there are no concrete plans as far as I know.

Having a stable release to maintain means that we developers need to be careful with the API of new functionality we want to add, and only release after the API is "set in stone" and the results tested in down stream packages. I do not want to release new functionality less frequently just because we have a stable release to maintain. This tells me that we need to make release candidates and use these in down stream packages in some way (in their own release candidates?). I'm quite comfortable releasing a 2.0 etc. if our needs require it.

I think we agree that diffsims should use orix more, and I'm sure some changes in orix are required to accomodate all usages there. We should look at this prior to a 1.0.

[hakonanes]

I'd like to settle #198 before considering 1.0 as well.

[pc494]

Broadly, my motivation for a 1.0 is to more accurately convey in the context of academic open source software where the codebase is. Although we should be strict to semantic versioning, I think downstream researchers will understand that perfect regression testing isn't feasible with the kinds of resources we have.

Instead, I want potential new users to turn up and have some (justified) confidence in the code. Making major (2.0,3.0 etc) releases once every 18 months is reasonable. Nobody is (nor should they be) deploying this code to run mission critical functionality, it's research software and a 1.0 release acknowledges that it's pretty well maintained by the those standards (though I say so myself).

[hakonanes]

Sounds reasonable.

As mentioned, I'm OK with planning for 1.0 instead of 0.9. It seems like we all agree, so I'll re-work milestones accordingly.

[hakonanes]

I've had a pass at open issues (no bugs to fix!) and tagged the ones I'd like to see implemented before 1.0.

It would be good if people could open issues with any functionality they would like to have before 1.0.

[pc494]

I think mine are more likely to be deprecations and refactors, will have another scan when I get some time but I think I had raised most of them when I saw them (eg #218 and #207)

[harripj]

I think #300 is important before a 1.0 release.