Re: On the quest for a new release model

[Greg Hogan <code@greghogan.com>]

On Fri, Dec 13, 2024 at 8:02 AM Suhail Singh <suhailsingh247@gmail.com> wrote:
>
> Ricardo Wurmus <rekado@elephly.net> writes:
>
> > Releases are made a short time after the core team branch is merged.
> > This would give us a new release whenever e.g. the default GCC and
> > glibc is bumped up.  We could aim for a release two months after the
> > merge to allow for minor fixes after the merge.
>
> I think agreeing on and following a release schedule is the crucial
> part.  Both for how frequently core team branch is merged
> (aspirationally) as well as how long (roughly) after the merge the
> release is made.
>
> I propose that we have a time-based release model rather than a
> feature-based one (similar to the Linux kernel).  However, what's
> perhaps even more important is to have a release model that we adhere
> to.

Having relatively recently asked [1] about a "1.5.0" release, I think
temver should be preferred over semver. What information has been
conveyed by Guix's version numbers beyond the symbolic "1.0"? Many
user-facing projects have adopted temporal versioning, including
NixOS.

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.

Greg

[1] https://lists.gnu.org/archive/html/guix-devel/2024-09/msg00018.html