MIME-Version: 1.0
References: <3824aef2-8af2-d33a-47e3-c7c66bd6615e@dereferenced.org> <20210409160505.52ac106b@ncopa-desktop.lan>
In-Reply-To: <20210409160505.52ac106b@ncopa-desktop.lan>
From: Led <ledest@gmail.com>
Date: Fri, 9 Apr 2021 18:05:40 +0300
Message-ID: <CAAO3vZ8GMFuchKEF6qa4BA9yY6+QD6-uCaXCqqSwVOfH5MSHUQ@mail.gmail.com>
Subject: Re: [3.15] System change proposal: rename the Alpine 3.15 release to
 Alpine 15
To: ~alpine/devel@lists.alpinelinux.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

+100.

It looks like some are bored and they are trying to bury another
project on a bunch of non-technical issues :(

=D0=BF=D1=82, 9 =D0=BA=D0=B2=D1=96=D1=82. 2021 =D0=BE 17:08 Natanael Copa <=
ncopa@alpinelinux.org> =D0=BF=D0=B8=D1=88=D0=B5:
>
> On Thu, 8 Apr 2021 20:29:43 -0600 (MDT)
> Ariadne Conill <ariadne@dereferenced.org> wrote:
>
> > Hello,
> >
> > Alpine has traditionally used the major version to represent the curren=
t
> > ABI version the system uses.  For example, Alpine 1.x was uClibc withou=
t
> > NPTL, Alpine 2.x was uClibc with NPTL and Alpine 3.x is based on musl.
> >
> > With the current ABI being evergreen, and our having moved past the 3.1=
4
> > release, it no longer makes sense to keep the 3.x designation.  When th=
is
> > was previously proposed, the primary request was to postpone this
> > discussion until after Alpine 3.14 release.  With the Alpine 3.14 relea=
se
> > imminent, I believe now is a time to bring this up again.
> >
> > An argument could have been made to jump to Alpine 4.x with apk-tools 3=
,
> > but we have decided to implement apk-tools 3 out in a way that is
> > non-disruptive.  So that argument is now moot, as well.
>
> The 2.x -> 3.x jump or 3.x -> 4.x indicates that there are breaking
> changes or incompatible changes. We don't do many of those, but what if
> we did? What if decided to switch to glibc or something else?
>
> The apk tools 3 may also be a better time to switch to 4.x, because it
> will change the database format.
>
> > ## Benefits to Alpine
> >
> > As the `3.` part of the version is now effectively meaningless, it is
> > helpful to downstream consumers of Alpine to have a simplified versioni=
ng
> > scheme.  For example, postmarketOS can say "based on Alpine 15" instead=
 of
> > "Alpine 3.15" which sounds better.
> >
> > Yes, to be brutally honest, this is an entirely marketing-related thing=
,
> > and there is no technical benefit either way.  However, this versioning
> > scheme is more aligned with other Linux distributions.
>
> There are costs with it though.
> - lots of scripts will break and needs to be modified
> - we need to spend time on communicating it to the users
> - there is currently a docker:3 tag which make sure that uesrs gets
>   latest 3.x docker image, but not 4.x. they will no longer get updates.
> - we will need spend time on long discussions on things like "why
>   don't we call it 2021.10.x? or 4.x?", "why dont we do real semver?"
>   how do we deal with patch releases?
> - regardless of what we change it to, there will be people complaining.
>   changes are always painful for someone.
>
> > ## Implementation Plan
> >
> > Set the version of `alpine-base` to `15_alphaXXXXXXXX` instead of
> > `3.15_alphaXXXXXXXX`.
> >
> > ## Contingency Plan
> >
> > If we decide we don't want to do this, we just downgrade `alpine-base`
> > back to `3.15_alphaXXXXXXXX`.
> >
> > Ariadne
>
> I'm not entirely against the idea, but I wonder if it wouldn't be wiser
> to spend the time and energy on something that gives some technical
> benefit while doing a breaking change. For example, rename the v3.14
> release branch to 3.14-stable so it corresponds with the git branch,
> and rename git 'master' branch to 'edge'. It would also be a breaking
> change, but there would at least be some technical benefits. scripts
> could be simplified.
>
> Or build a better building infra.
>
> Or write a better test suite for abuild.
>
> There many other things that I'd like to prioritize over a version
> change. But that's just me I guess.
>
> -nc



--=20
Led.