New release

[jadball]

It would be wise to do a new release relatively soon before we overhaul the dataset class and notebooks accordingly, as those are big changes, and it gives the Ewoks task developers a stable pypi version to develop against in the meantime.

[jonwright]

Ideally, it would be good to fix these:

• FrelonSegmenterGui: Extract choose_frame and segment_frame as functions #368
• Getting cumulative sums and masks value out of select_ring_peaks_by_intensity #369
• pbp indexer - y0 not added in grid and units for diffty not matching distance #366
• TensorMap slow import #352 if it is just to write cache=True in the decorators
• point_by_point.compute_tth_eta_from_xyz does not respect translations #381
• Run / test the notebooks from the command line automatically #334 if the release is going to be tested
• notebooks are not in the install #281
• Problem with guess_bins with 360 degree scans #328 not sure if this was fixed already?
• refactor properties.py - 4d peak labelling #265 try to remove the monkeypatch at least

[jadball]

Agreed - this gives a good timeline for our overall development plan. The above bugfixes first, followed by a new release, then we begin our various overhaul tasks:

• Simplify Dataset Class #370
• Extended Analysis Schema #372
• Processing Parameter and File Management #373

[loichuder]

and it gives the Ewoks task developers a stable pypi version to develop against in the meantime.

Thanks for considering this, much appreciated 🙂

[loichuder]

Related to this, the version number is still 2.0.2 in the init_.py file: https://github.com/FABLE-3DXRD/ImageD11/blob/ff48f8b4461ebb8468e02b87c55d6d6236a524f4/ImageD11/__init__.py

But according to the Releases page, we are now at 2.0.4 ? Shall I bump the version number ?

[jonwright]

Sure, yes please. Seems we should be at 2.0.5 for master and perhaps bump to 2.1.0 for the release. I would like to init.py to know about the current git tag, but I didn't see something which works from a live repo (e.g. it would need to call git log {os.path.split(__file__[0])} for source, or have a tag introduced during a build).

I would like to check in with @t20100 to remember how to get the wheels built and figure out the a checklist of things to do when releasing. The 2.0.4 vs 2.0.2 was due to some mistake last time. Something like:

• update version in init and also in README.md
• remember to create a git tag (and branch?)
• build+check the wheels

Apart from the issues listed above, I have now remembered:

• Do we continue to force numpy<2? See Update numpy build dependency and use macos-13 in release workflow jonwright/bslz4_to_sparse#5 . Or do we build wheels that will break on older numpy installs? I am happy to force numpy<2 forever...
• Make sandbox importable #255 looks easy to fix

[loichuder]

Yes, releases are always a mess. We try to automate them as much as possible but there are dozens of ways of doing it and you still have to take decisions down the line.

In anycase, the best you can do is as you just said, have a checklist of things to do when releasing, and follow it religiously each time.

[t20100]

Your release process should be close to the one of silx since the github workflow is very similar ;).
There is unfortunately nothing checking that the tag version is the actual version of the package, did you make the v2.0.4 release by hand?

There's now a "how to make a release" doc in silx: https://github.com/silx-kit/silx/blob/main/CONTRIBUTING.rst#how-to-make-a-release
That can be adapted for ImageD11.