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.
I think the current developers working on QGC have very clear tasks that overlap with QGC but are not necessarily related to the upkeep/maintenance of the project, which is what we were discussing.
My understanding is that currently we do a QGC release following PX4 cycle - mostly because if we don’t there is no official QGC release that works with current PX4. We also do a daily build via CI.
Whatever else we do, we need a PX4 v1.14 compatible QGC release to be in a release cycle now. Is that already happening?
What you are both saying makes sense.
@rroche is right - we need something in place to encourage our users to get involved with releases, or it won’t happen.
@JulianOes is right - we might not have resource for this kind of cycle. Though if we do, we can call it a “Bi-monthly release” to make him happy
I don’t think we can afford to do nothing.
@rroche Do you think we have the resource for this? Who would do the release notes? Who would cut the release and do blogs? Who would do the regular back port of bug fixes into that release? I guess is we have a short cycle this is not as onerous.
Is there another option? Could we actually do a rolling release - i.e. make our daily build the official release build? (it generally seems pretty stable). This would mean we’d have no backporting of fixes etc. (or perhaps nominate some daily build as the current release every week or so).
This might make more sense given the resources we have, albeit we might need to increase the automated testing.
