Re: Release v1.4 (or 2.0): process and schedule ?

["Ludovic Courtès" <ludo@gnu.org>]

Hi,

zimoun <zimon.toutoune@gmail.com> skribis:

> On Sun, 19 Dec 2021 at 21:12, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:
>> zimoun <zimon.toutoune@gmail.com> writes:
>
>>> Now core-updates-frozen is merged.  Now The Big Change [1 ]is done.  Do
>>> we go for v1.4 or v2.0?
>>
>> As I've mentioned previously, I'd go for a 1.4.0 release, since overall
>> we've refined and improved (greatly!) what we already had rather than
>> introduced something revolutionary.  I'd keep a 2.0.0 for when we have
>> p2p distributed substitutes, a custom graphical tool and/or integration
>> with the 'Software' application in GNOME, this kind of big user-facing
>> changes.  But that's just my personal opinion :-).  If the majority
>> feels a 2.0.0 is more suitable, I won't mind.
>
> I do not have a strong opinion either.

Same here.  But first it’d be nice to come up with a summary of what we
did in ‘core-updates’ because I think we’ve all forgotten most of it.
:-)

[...]

>>> In both case, what is the target for a release date?  I propose January
>>> 31rst.  WDYT?
>>
>> I'd like to fix #52051 before issuing the first release candidate (RC).
>> Assuming this can be made before the end of January with the first RC
>> coming out around New Year, and that the kind of collaboration I've seen
>> in the last weeks continues at the same intensity, this seems
>> achievable.
>
> To me,
>
>  - adapt the importers with the new style is also a thing
>  - various guix home minor fixes discussed [1] by Xinglu, Andrew and
>    Ludo, a blog post would be neat too. :-)

Agreed on all this.

I’d also like to see if we can avoid the two-step “make release” process
by updating the ‘guix’ package once only.

And also see if we can arrange for ‘guix system init’ to hard-link files
instead of copying them during the normal installation process
(currently it copies files from /tmp to /gnu on the installation media).

Probably at some point we should open a bug for the release and mark
other items as blockers, like we did for the previous release.  One of
us could then keep track of things and send weekly updates, say (it’s
best if it’s someone not too deeply involved with the actual release
hacks!).

Ludo’.