Date: Fri, 9 Apr 2021 16:05:05 +0200
From: Natanael Copa <ncopa@alpinelinux.org>
To: Ariadne Conill <ariadne@dereferenced.org>
Cc: ~alpine/devel@lists.alpinelinux.org
Subject: Re: [3.15] System change proposal: rename the Alpine 3.15 release
 to Alpine 15
Message-ID: <20210409160505.52ac106b@ncopa-desktop.lan>
In-Reply-To: <3824aef2-8af2-d33a-47e3-c7c66bd6615e@dereferenced.org>
References: <3824aef2-8af2-d33a-47e3-c7c66bd6615e@dereferenced.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

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 current 
> ABI version the system uses.  For example, Alpine 1.x was uClibc without 
> 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.14 
> release, it no longer makes sense to keep the 3.x designation.  When this 
> was previously proposed, the primary request was to postpone this 
> discussion until after Alpine 3.14 release.  With the Alpine 3.14 release 
> 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 versioning 
> 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