I would like to know your opinion about having more patch releases of Orekit.
Currently, Orekit mostly has minor and major releases. Patch releases are only used to fix important bugs in the library. However, a patch release can also be used to fix few issues (about 4-5) and thus allow users to benefit from some bug fixes between minor or major releases.
From a user’s point of view, it can be frustrating to wait weeks or months for a stable version of Orekit that contains a bug that has been fixed in the develop branch for a long time. So introducing more patch versions would have the advantage of reducing this waiting time for users.
In my opinion, I think that having about 2 patches between two minor/major versions can be very beneficial for the users without increasing considerably the work time of the developers.
If the OREKIT team can manage the additional overhead, from the user perspective I see only benefits: regular bug fixes helps to mitigate risk and thus drive uptake.
All power to your elbow (as we say in the UK)
I am all for more frequent release, and this has always been my view, but obviously, we never succeeded in doing that (and I’m the first one to blame for this).
Hope it will work this time.
I think doing more frequent backward-compatible releases would certainly be useful to users.
Having performed a release it takes a significant effort to ship the code. I probably could have fixed a couple issues with the amount of effort it took to release Orekit, so there is a cost to doing more releases. Given the choice I would rather add a new feature, though releases are important too.
I think if we want more frequent releases we should look for ways to streamline the release process so that it less of a burden on developers. Currently it is a long process with many manual steps, many of which are repeated several times when a new RC needs to be made. [1] Ideally there would be a single button (or script) to create an RC and one to promote an RC.
Perhaps scripting some of the steps in the guide or integrating with GitLab CI. Some of the checks for warnings should probably be integrated into the normal CI build so that they are checked for every MR. There seems to be some pointing and clicking that could be done with APIs and editing of files that could be done with sed. Just some ideas.
The release of a patch is lighter than that of a major or minor version:
You don’t need to create a release branch
You don’t need to update the maven plugins version
You don’t need to update the documentation (a patch must not change the API or the architecture of the library, otherwise it is not a patch but, at least a minor version)
According to the Orekit governance, you don’t need to organize a vote and wait for the PMC to give its approval (because a patch does not modify the API, nor the architecture, nor the functional scope of the library)
You don’t need to close the current milestone
But I agree with you, everything that can be automated should be. We’ve made improvements in this area over the past year, but we need to go further.
All the points presented by @sdinot are the main advantages of the patch release (from a release manager point of view). That’s why I proposed to increase the number of patch release between minor and major releases, because they can be done in just 2-3 hours (and they make users happy).
For the latest releases of Orekit, I needed about 1 day to follow the release process. Most of this time is spent waiting (i.e., unit tests are executed 3 times during the process, without any change in the code between). Because I’m a coffee addict, it’s not a promblem
Jokes aside, I agree that more things can be automated.
I would like to do the 11.0.1 very soon (i.e., before the end of the next week). I will see how many time it needs to follow the patch release process.
Also, I think we must add in the release guide the tasks to follow (or unfollow) for a patch release.
That is a good idea Bryan about updating the release guide for patch releases. I was unaware of the all the things we don’t have to do for patch releases. Thanks for clarifying Sébastien.
As you have decided to release more patches (that’s great!), we have started thinking about the release process, in order to make it less time-consuming as possible.
While reviewing the release guide, we realized that some of the website updates, previously done manually, could be automated. This automation has been carried out and some operations indicated in the release guide are no longer necessary. I have just published a merge request removing the related instructions from the release guide.
We have some other improvements in mind, not about the website, but about the process itself. We will share our ideas with you here soon to see what you think.
