QGC Dev Call: May 04, 2023

May 04, 2023

Join us


  • Releases
  • Community Q&A
  • In-Depth discussions (optional)

Attendee List


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.