Re: On the quest for a new release model

[Efraim Flashner]

On Fri, Dec 13, 2024 at 01:03:05PM +0100, Ricardo Wurmus wrote:
> Hi,
> 
> Thanks for moving this discussion forward.  I do think we need much more
> regular releases.
> 
> > - devel as the branch for developments, master for releases and
> >   security/bug fixes
> 
> Changing the branching model is very difficult to do.  I think it is
> better to ignore branches for now and focus on coming to an agreement
> about more frequent releases, lest this discussion, too, ends up
> reiterating "stable" branches and the finer points of release
> maintenance.
> 
> > - major should follow core merges to devel
> > - minor should follow non-core teams merges
> 
> I think this is a good idea to start with.  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'm not sure if these merges should justify a new *major*
> release, but I think it is good to have a new release then.
> 
> Not all team branch merges may justify a new release.  The r-team
> branch, for example, usually contains just a couple hundred patch-level
> package upgrades that are restricted to packages from CRAN and
> Bioconductor.  It is only sometimes that the R version is increased or
> the Bioconductor release version is changed --- only in those cases I
> would consider it appropriate to bump up the Guix minor (or patch-level)
> version number.

Since, IMO, the major uses of the actual guix package is for the daemon
and the installer, I think we could tag a minor release just about every
time we bump the guix package.

Lets make releases boring :)

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

signature.asc
Description: PGP signature