Proposal for a new rolling release cycle
With the maintainer team’s limited time to support this project, we think it’s best to put scheduled releases in place. We oftentimes let a big window of time pass between releases increasing the burden on the maintainers to produce a stable release while not offering contributors a clear timeline for releasing their contributions. Scheduled releases allow the maintainers to focus on clear goals while also helping define the tasks expected from a maintainer, bringing visibility and transparency to the role and making recruiting maintainers from the community easier.
Eight weeks with semantic versioning
Rolling release with the following stages
Testing Release Candidates: 2 weeks
Merge Window: 6 weeks
After the window closes, we branch out from the main branch into the release branch
Development can carry on main for the next rolling release
Release Sign-Off: Happens during the bi-weekly meeting
Bugfix backport commits into the release branch merit a point release for bugfixes
In-Depth discussions (optional)
For smaller groups expanding technical discussions, stay until the end and follow up.
If you have any feedback or corrections, please comment on this post.
I would like to help with this but I have a couple of comments
Rolling release
While I don’t object to this model I would not call it a rolling release model.
To me, a rolling release would be a release after each PR that’s merged, or at least every day.
If you look at a “rolling release” distro, then it means you just get the updates of each component as you go, but you never select an actual version number.
Semantic versioning
Then when talking semantic versioning that sounds great, since in the past that has been quite confusing.
However, we need to define what the semantic versioning is related to. My guess would be that it would be with respect to the UI/UX, so only user facing. For example:
Remove a tab from QGC: major change
Change the way the mission planning works: major change
Add a feature: minor change
Fix a bug: patch change
Internal refactor: minor change?
Release schedule
To me this sounds too complicated given not much of a maintenance team.
Having release candidates, testing windows, merge windows, release branches, backports, all of that creates work for a maintainer.
Instead, the whole point of releasing often is that it does not require all of that, no merge windows, no release candidates, no release branches, no backports! The releases come and go, and whatever makes it in, makes it in.
And that’s actually why I would not bother with a fixed schedule either. I would just release often.
For example:
What if a release was done, and one week later a bug is found? Well, patch the bug, release a patch release, everyone happy.
What if several nice features have been merged. Well, let’s cut a release and get it out there. Done. Well, we could have done a release candidate but that requires tooling, tracking, testers, and feedback, none of that is likely. Instead, release it. Once bug reports come in, fix it.
Now what if we don’t have a release for weeks and many things have been merged in the meantime. Well, let’s check in the call every two weeks if we should have done one in the meantime.
