Re: On the quest for a new release model

[Suhail Singh <suhailsingh247@gmail.com>]

Greg Hogan <code@greghogan.com> writes:

> We only need a release team and a documented release process. Releases
> should be scheduled rather than depending on other teams. What benefit
> is there to the Guix user when glibc or the default gcc are updated?
> You're only a "guix pull" away from updated packages.
>
> As I recall, one issue for past releases was having to freeze all
> development on the master branch. With the new teams-branches model
> the release-team branch is just another branch, moving to the queue
> when ready to cut a new release.

My sentiments precisely.  Thank you, Greg, for describing the situation
clearly.

If the goal is to increase the frequency of releases while maintaining
quality, the only consideration that the teams-branch ought to make is
to ensure that the commit in question (corresponding to the release)
builds correctly (i.e., may, in future, do some automated testing beyond
the test suites included in the individual packages) past some threshold
(i.e., on platforms of interest etc.).  Importantly, instead of making a
release soon after a major merge, such a team may decide to not make a
release too close to major changes.

However, to me, the release cadence is orthogonal to how we do the
versioning.  It's possible for a project to have time-based releases
while still using semver.  I propose that this thread be only about the
release process, and that the discusssion about the versioning happen in
a different thread.

-- 
Suhail