Re: On the quest for a new release model

[Vagrant Cascadian]

On 2024-12-15, Efraim Flashner wrote:
> On Fri, Dec 13, 2024 at 01:03:05PM +0100, Ricardo Wurmus wrote:
>> > - 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.

Hear, Hear!

I would like to encourage partial releases, e.g. a release where the
installer is tested and updated, a release where guix-daemon is updated,
and a "full" release closer to what has traditionally been done...

Not every release needs to support everything... it just needs to be
able to bootstrap up to the current guix... and the fewer steps to
bootstrap, the better... being clear about what the focus of each
release is might help?

If there is the occasional "bad" point/mini/micro release, it can be
flagged as such or something. Or even using alpha/beta/release-candidate
snapshots more often. Anything nudging towards something more
incremental...

As the maintainer of the guix package in Debian, regular point releases
with the new guix-daemon would be really, really nice. About to hit a
freeze cycle in Debian again, and no guix release in sight since the
last Debian stable release... I *might* just break down and package a
git snapshot... but tens of thousands of commits to choose from!


> Lets make releases boring :)

Yes!

live well,
  vagrant

signature.asc
Description: PGP signature