Subject: [3.15] System change proposal: rename the Alpine 3.15 release to Alpine 15

From: Ariadne Conill <[email-masked]>
Date: Thu, 8 Apr 2021 20:29:43 -0600 (MDT)

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.

## 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.

## 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

---

From: maxice8 <[email-masked]>
Date: Thu, 08 Apr 2021 23:51:50 -0300

> back to `3.15_alphaXXXXXXXX`.

Hello

+1

Regards
Leo

---

From: Zach van Rijn <[email-masked]>
Date: Fri, 09 Apr 2021 00:12:58 -0500

On Thu, 2021-04-08 at 20:29 -0600, Ariadne Conill wrote:
> ...
> 
> 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.

I think it would make more sense to start at "4" without minor
releases, instead of "15", for the following reasons:

(1) It is logical to go from 3 to 4 and will avoid confusion in
    the interim while everyone gets used to the new scheme;

(2) "Alpine 4 is out?" sounds better than "Alpine 15 is out?"
    (followed by "What the heck is Alpine 15?");

(3) It affords more releases before the numbers become huge and
    unwieldy, however these point releases [0] should probably
    not become { 5, 6, 7, ... 81, 82, 83 } in the near future.

Depending on how often the version /needs/ to be incremented, it
could make sense to follow a schedule with more regularity, e.g.
that of Fedora [1]. Personally, this would not be my preference.

> ...
> 
> 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.

It may also make sense to keep the version number in sync with
your GCC major (i.e., start at "10"), as it would make somewhat
clear what is expected to be compatible ABI-wise [2] if folks are
using Alpine environments (read: containers are ubiquitous) to
build and link their software. But, this isn't a strong argument.

In any case, I don't see a strong incentive to start this scheme
at "15", but I don't see a strong reason to keep points.

ZV

[0]: https://alpinelinux.org/posts/
[1]: https://en.wikipedia.org/wiki/Fedora_version_history
[2]: https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html

---

From: Ariadne Conill <[email-masked]>
Date: Thu, 8 Apr 2021 23:22:39 -0600 (MDT)

Hi,

> releases, instead of "15", for the following reasons:

The last time we had this conversation, the conclusion was that simply 
chopping the "3." part off made the most sense.

>    the interim while everyone gets used to the new scheme;

Obviously some explanation will be required for the version scheme change, 
but this is the 15th release series for the (evergreen) musl ABI.  I think 
most people will understand the context.

> that of Fedora [1]. Personally, this would not be my preference.

We do two release series per year, generally on a six month cadence.  So, 
15 would be followed by 16, and so on.  It will take several decades 
before this becomes a problem.

Ariadne

---

From: Nico Schottelius <[email-masked]>
Date: Fri, 09 Apr 2021 09:29:54 +0200

Good morning,

> chopping the "3." part off made the most sense.

I've to confess I'm with Zach here. Alpine 4 would be much more logical
than doing a jump to Alpine 15. I personally think it will actually give
the wrong impression as everyone will see it as a "marketing joke".

If you want to present Alpine as a serious project, I suggest to bump
(not jump) to 4.x, reasoning that there is a new apk-tools as a basis.

Jumping discredits the seriousness of the project and I doubt this is
smart long term decisions.

Cheers,

Nico

--
Sustainable and modern Infrastructures by ungleich.ch

---

From: Shiz <[email-masked]>
Date: Fri, 9 Apr 2021 11:23:35 +0200

> On 9 Apr 3 Reiwa, at 09:29, Nico Schottelius <[email-masked]> wrote:
> 
> 
> Good morning,
> 
> 
> the wrong impression as everyone will see it as a "marketing joke”.

+1.

- Shiz

---

From: Leonardo Arena <[email-masked]>
Date: Fri, 9 Apr 2021 11:42:31 +0200

+1

/eo

---

From: "Francesco Colista" <[email-masked]>
Date: Fri, 09 Apr 2021 11:58:14 +0000

>> the wrong impression as everyone will see it as a "marketing joke”.

+1 fpr Alpine 4

.: Francesco Colista
.: Alpine Linux Core Dev Team

---

From: Konstantin Kulikov <[email-masked]>
Date: Fri, 9 Apr 2021 14:03:26 +0300

Please consider using dates for versions, like ubuntu. Every time I
hear "buster", "big sur", "lollipop" or "freebsd 12" I have no idea if
the person is talking about recent version or a dated one.

---

From: Bart Ribbers <[email-masked]>
Date: Fri, 09 Apr 2021 13:17:31 +0200

Hi,

> the person is talking about recent version or a dated one.

We currently do this at postmarketOS (which is based on Alpine Linux). We had 
a stable release of 20.05 which was made in May in 2020. We just released 
21.03 which was made in March in 2021. Both are based on stable releases of 
Alpine Linux (20.05 == 3.12 Alpine and 21.03 == 3.13 Alpine).

I will +1 this suggestion as it's not just more clear for everyone using 
Alpine, it's also more  clear for people using postmarketOS.

> > back to `3.15_alphaXXXXXXXX`.

Bart

---

From: Natanael Copa <[email-masked]>
Date: Fri, 9 Apr 2021 16:05:05 +0200

On Thu, 8 Apr 2021 20:29:43 -0600 (MDT)

> 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.

> 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.

> back to `3.15_alphaXXXXXXXX`.

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

---

From: "Marcus Rohrmoser" <[email-masked]>
Date: Mon, 12 Apr 2021 00:57:50 +0200

On 9 Apr 2021, at 16:05, Natanael Copa wrote:

> spend the time and energy on something that gives some technical benefit

+1

(and please don't go for 3.141... either)

---

From: Jakub Jirutka <[email-masked]>
Date: Fri, 9 Apr 2021 16:43:13 +0200

Hi,

I completely agree with ncopa. I don’t see any real value in this change, actually the opposite.

Dropping the major version number would be unreasonable; it’s not meaningless and it’s actually a good thing that we don’t increment it too often. We may need or want to introduce some major breaking change in the future (for example, dropping FHS in favour of /package hierarchy) that will require a bit complicated upgrade path. In such case, incrementing the major number, that has not changed in the recent years, clearly communicate to the users (and various automation scripts) that there’s some important change.

>> 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.

I think that this speaks for itself… Do you really wanna waste precious time of volunteers on such meaningless thing, that has zero benefit for the users, just because it “sounds better” and “others do it too”? Really?!
Don’t get me wrong, I’m not against changes per se and I understand the value of marketing, but I see very low marketing value here, (semi-)technical drawback (mentioned above), breaking unknown number of automation scripts and workload to fix stuff, update documentations etc. All in all, negatives predominate. Also, I hope that we all agree that technical reasons should have always the highest priority.

Akso as ncopa said, there are tons of much more important tasks to do that would have actually positive benefits.

Jakub J.

---

From: Ariadne Conill <[email-masked]>
Date: Fri, 9 Apr 2021 11:52:07 -0600 (MDT)

Hi,

> Dropping the major version number would be unreasonable; it’s not meaningless and it’s actually a good thing that we don’t increment it too often. We may need or want to introduce some major breaki…

It is true that we may have a breaking change in the future, but I am not 
sure that it is that likely.  Even the apk-tools 3 changes are planned to 
be non-breaking.  The overall mantra has been to avoid breaking changes 
after the uClibc to musl switchover, and we've delivered non-breaking 
changes for other major disruptions (like musl 1.2 / time64).

> Akso as ncopa said, there are tons of much more important tasks to do that would have actually positive benefits.

Yes, the main purpose of this thread was largely to revisit the topic, 
since last time, we concluded further discussion was needed.

I don't really care per se if we stick with 3.15, or call it 4.0 because 
of apk3, or whatever.  The docker `alpine:3` tag argument is somewhat 
compelling, so I think Natanael convinced me that the [3.] still has value 
in that regard.

Thanks for your feedback!

Ariadne

---

From: Rasmus Thomsen <[email-masked]>
Date: Fri, 09 Apr 2021 16:57:54 +0200

Hello,

> will change the database format.

+1 on this, I think switching to 4.x for apk-tools 3 makes perfect
sense and I think it makes sense to keep this for future releases since
we'll have to break compatibility at some point in the future for some
change again.

> change. But that's just me I guess.

Yup, I think the time is better spent on other things. Changing the
versioning scheme tends to pull in a massive rat tail of other changes
as well. E.g. with the GNOME versioning change (the version that was
suppose to become 3.40 became 40.0) lots of things had to be fixed:

* appstream-glib didn't work with how the new versioning scheme worked
for alphas/betas and had to be patched
* Most infra related scripts had to be changed so they didn't expect
[1-3].x in the paths
* Maintainers had to be informed (and many didn't know about the change
so many packages were released with 3.40 anyway - I imagine many docker
images would have the same thing happen to them).
* Distro maintainers & users had to be informed - many missed this too
and/or had to adjust their scripts as well to properly pull in the new
version.

I can understand how a simpler version scheme can seem nice at first
but IMHO it'd be a huge undertaking to make it happen only so we have a
simpler version number that contains less useful information.

-1 from me.

Regards,

Rasmus Thomsen

---

From: "Tyler G. Sherrard" <[email-masked]>
Date: Fri, 09 Apr 2021 17:41:47 +0000

+1 for this

> -   appstream-glib didn't work with how the new versioning scheme worked
> -   Most infra related scripts had to be changed so they didn't expect
>     [1-3].x in the paths
>
> -   Maintainers had to be informed (and many didn't know about the change
> -   Distro maintainers & users had to be informed - many missed this too

---

From: Led <[email-masked]>
Date: Fri, 9 Apr 2021 18:05:40 +0300

+100.

It looks like some are bored and they are trying to bury another
project on a bunch of non-technical issues :(

-- 
Led.

---

From: Ariadne Conill <[email-masked]>
Date: Fri, 9 Apr 2021 11:29:25 -0600 (MDT)

Hi,

> project on a bunch of non-technical issues :(

I maintain a large chunk of the base system, and have written numerous 
utilities in the distribution from scratch, such as ifupdown-ng, 
libucontext and pkgconf.

Please stop harassing me.

Ariadne

---

From: Natanael Copa <[email-masked]>
Date: Mon, 12 Apr 2021 12:12:41 +0200

On Fri, 9 Apr 2021 11:29:25 -0600 (MDT)

> Please stop harassing me.

FWIW,

Alpine would not been what it is today without Ariadne and she
absolutely deserves our respect.

I don't think the version idea is stupid, and I don't think we should
underestimate the value of marketing. I just don't think it is worth
the cost, at least not now.

We also want avoid that anyone feel harassed, regardless if that was
the intention or not. Having a friendly community is a high priority
goal.

Thank you to everyone who express ideas, options or disagreements in a
respectful way - regardless if the respect is deserved or not.

-nc

---

From: Nico Schottelius <[email-masked]>
Date: Mon, 12 Apr 2021 12:45:08 +0200

Good morning,

I would like to strongly second Natanael's argument, because we are an
Open Source community that consists of and relies on many volunteers.

It is ok (and good) to be of a different opinion, but this should always
be expressed respectfully.

I'm looking back on 20 years of FOSS community work and I can say that
too long has the computer science / IT nerd / FOSS scene not taken this
seriously enough.

We shall disagree, we shall even fight about topics, but we must always
keep it respectful.

If we, who else should be a role model?

Aside from all this, Alpine is a real fun project and while I disagree
with Ariadne about the versioning proposal, the whole project is so much
fun - so let's keep it fun.

Cheers and greetings from a snowy (again!) Switzerland,

Nico

p.s.: I know I might sound old and I know it's an old term, but "the
tone makes the music".

---

From: Kevin Daudt <[email-masked]>
Date: Fri, 9 Apr 2021 20:24:48 +0200

> project on a bunch of non-technical issues :(

Led,

We do our best to make and keep the Alpine Linux community a friendly
place where everyone feels welcome, and this behavior is detrimental to
that goal.

On several occasions, you attack Ariadne personally and that's against
our [Code of Conduct][0]. Ariadne asked you to stop, but you keep
continuing.

You are free to discuss things on their technicaly merrit, but stop
making ad-hominem attacks.

Consider this your final warning.

Kevin

[0]:https://alpinelinux.org/community/code-of-conduct.html

---

From: Christian Dietrich <[email-masked]>
Date: Fri, 9 Apr 2021 17:30:42 +0200

> 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 

As an end user, I can tell you that the current version scheme is very 
easy to understand.
Changing the current version scheme as a marketing tool, on the other 
hand, tends to make a negative impression on me.
If I read somewhere about "Alpine 15" I certainly don't think about 
Alpine Linux either.