I think it would be good to start the release process for 3.8, because we already have quite a backlog of nice changes. I propose to start with a 3.8-beta1 version to test the waters.
One interesting new change is the availability of the new Windows installer, meaning that we will offer three different Windows packages. I wonder if we should drop the Windows without Java Zip archive to simplify things a bit.
Are there any changes you would like to get merged before such a release?
If you feel like it, feel free to help out to draft the changelog on the wiki.
Are there any changes you would like to get merged before such a release?
I have 6 features and 17 bug fixes tagged with the 3.8 Milestone. Is it safe to assume that they'll all be included?
Pending / in-process things that I think would be worth considering to include:
5902/6146 - CSS spinner from Albin (a designer just needs to pick the spinner to use)
6140 - correctly encode URLs before using them to fetch
6058 - report XML parse errors on import (the fix for this is currently on a branch with an error reporting refactoring, but could be separated out if the 3.8 release is time critical)
6253 - report error when attempting to import invalid Zip archive (same as above)
6009 - make a decision about what to do about the (5 year old) date parsing regression. If the decision is to just document the regression, make sure that documentation is included in the 3.8 release notes (among other places)
I've added the 3.8 milestone to these so that we can track them, but feel free to adjust based on team consensus. Others should feel free to tag their high priority issues with the milestone as well.
I would love to see Catalan shipped with the new release. I'm doing a push to translate all the strings. I hope to finish in a week or so. Would that be in time for the new release? Thanks.
@tfmorris I would follow the same process as for the last few releases: create the 3.8 release branch by branching off from master. So, all PRs merged before this release would be included. I have started composing the changelog on the wiki (I am in the process of tidying up the formatting and phrasing)
@Robertgarrigos amazing that you are aiming for a complete translation! For now according to Weblate, you are at 78%. All translations made before the release date will be included (because we are branching off master).
I would propose to do the 3.8-beta1 release soon, even though there are still open issues in the milestone. The changes for those issues could be added to subsequent 3.8 releases (such as other betas). Would that be fine?
I think it would be a useful way to get more eyes on our changes so far. Given that our snapshot releases are somewhat less accessible now that we are not using Maven Central to store them anymore, I suspect our master branch is not tested as much as for previous releases.
I've been offline most of January, so haven't really made any progress on any of my items. I'll see if I can tidy up any pending things over the weekend, but it shouldn't block the release. Some of the error handling/reporting changes should get extensive testing, if possible.
My understanding is that the date parsing regression #6009 will be documented as a "feature" (although I don't know if anyone created a ticket for that documentation).
My understanding is that the date parsing regression #6009 will be documented as a "feature" (although I don't know if anyone created a ticket for that documentation).
I am not sure what needs documenting there? Since this change did not happen between 3.7 and 3.8 I don't expect to write anything about it in the release notes at least.
My understanding is that the date parsing regression #6009 will be documented as a "feature" (although I don't know if anyone created a ticket for that documentation).
I am not sure what needs documenting there? Since this change did not happen between 3.7 and 3.8 I don't expect to write anything about it in the release notes at least.
The issue is that the behavior silently changed between versions so things aren't reproducible from one version to the next and we never informed the users. Adding documentation someplace would provide them with the information about the incompatible behavior.
I've been offline most of January, so haven't really made any progress on any of my items. I'll see if I can tidy up any pending things over the weekend, but it shouldn't block the release.
I think I've cleared the backlog and have PRs posted for everything that was assigned to me tagged with 3.8 milestone. I've unassigned myself from #6009 and will let someone else (Owen?) deal with it.
I've also got a GREL parser branch which has a number of bug fixes that I'll attempt to get cleaned up and posted, but most of that work dates from 2020, so obviously not time critical.
So far I don't think we had any particular sort of agreement about release schedules.
For now, I essentially do it when I get around to it. It's not a great criterion! Personally, I use OpenRefine in its development versions, I don't have an incentive to make a release to get access to a new feature or fix myself. Interestingly, it's very rare that people explicitly ask for a new release, or at least I don't see those requests myself. I would welcome being prodded more
One factor for the recent slow down is that we have been doing more patch releases, which meant being able to ship select urgent bug fixes more easily, but also decreasing the urge of publishing the rest of the changes in a stable release, in a sense.
Another factor is the internship periods: they generally come with a lot of changes which need some ironing out before a release. The last internship period got sort of extended as we retained both @Lydiaofficial and @Ayushi_Rai to make reconciliation improvements, so that contributed to making the release happen later. But I do note that @Ayushi_Rai would have welcomed getting her changes released earlier (and it's probably a motivation factor for most contributors), so it would be worth avoiding that sort of lengthy wait.
I remember @Martin suggesting we could aim for a particular cadence (was it two releases a year?).
Obviously this would need quantifying. Last year we did 11 releases if we count all betas and patch releases. We can aim for a specific number of stable major/minor releases, but we could also backport more bug fixes into patch releases of the current stable release series (currently 3.7) so that those get shipped faster, for instance.
Now that the packaging process is quite streamlined inside GitHub Actions, the vast majority of the effort to publish a release is concentrated on writing the release notes, updating the milestones, and doing small communication tasks around that. Getting a better process for writing the changelog would likely help with making more frequent releases.
I think Butterflys new ability to serve SVG files might deserve a mention in the "For developers" section of the release notes as it will allow people to migrate from PNG and GIFs.
I remember Martin suggesting we could aim for a particular cadence (was it two releases a year?).
A predictable, regular cadence would be good. Twice a year sounds OK, but certainly no less frequently than once a year. 3.8 will probably be something like 14 months by the time it's through beta.
There's something to be said for tuning the frequency to the amount of development activity. If not much is happening, there's really no point in doing releases just for the sake of doing them. If there's active development going on, the sooner we can get new features and bug fixes to customers, within reason, the better. Plus, as you mentioned, it's discouraging to contributors for it to take more than a year for their work to become useful to anyone.
We can aim for a specific number of stable major/minor releases, but we could also backport more bug fixes into patch releases of the current stable release series (currently 3.7) so that those get shipped faster, for instance.
Limiting patch releases to critical bug fixes and security updates minimizes the effort to prepare them, so I wouldn't change that. I think it's better to do more frequent point releases than heavier weight patch releases.
| 