~alpine/devel

21 17

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

Details
Message ID
<3824aef2-8af2-d33a-47e3-c7c66bd6615e@dereferenced.org>
DKIM signature
missing
Download raw message
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
Details
Message ID
<b6b8dd66fcd97bffad6860f3b1716c05613c29ca.camel@gmail.com>
In-Reply-To
<3824aef2-8af2-d33a-47e3-c7c66bd6615e@dereferenced.org> (view parent)
DKIM signature
missing
Download raw message
On Thu, 2021-04-08 at 20:29 -0600, Ariadne Conill 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.
> 
> ## 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

Hello

+1

Regards
Leo
Zach van Rijn <me@zv.io>
Details
Message ID
<8fa74683a260e4e9af058fa015e72d44574ad995.camel@zv.io>
In-Reply-To
<3824aef2-8af2-d33a-47e3-c7c66bd6615e@dereferenced.org> (view parent)
DKIM signature
missing
Download raw message
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
Details
Message ID
<28fd9b1a-878d-edc1-d5d0-899b3c5ffc9a@dereferenced.org>
In-Reply-To
<8fa74683a260e4e9af058fa015e72d44574ad995.camel@zv.io> (view parent)
DKIM signature
missing
Download raw message
Hi,

On Fri, 9 Apr 2021, Zach van Rijn wrote:

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

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

>
> (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;

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.

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

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
Details
Message ID
<87a6q73ogd.fsf@ungleich.ch>
In-Reply-To
<28fd9b1a-878d-edc1-d5d0-899b3c5ffc9a@dereferenced.org> (view parent)
DKIM signature
missing
Download raw message
Good morning,


Ariadne Conill <ariadne@dereferenced.org> writes:
> On Fri, 9 Apr 2021, Zach van Rijn wrote:
>
>> 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:
>
> The last time we had this conversation, the conclusion was that simply
> 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
Details
Message ID
<53F16841-6ABC-4887-AC36-F6EE20010CAE@shiz.me>
In-Reply-To
<87a6q73ogd.fsf@ungleich.ch> (view parent)
DKIM signature
missing
Download raw message

> On 9 Apr 3 Reiwa, at 09:29, Nico Schottelius <nico.schottelius@ungleich.ch> wrote:
> 
> 
> Good morning,
> 
> 
> Ariadne Conill <ariadne@dereferenced.org> writes:
>> On Fri, 9 Apr 2021, Zach van Rijn wrote:
>> 
>>> 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:
>> 
>> The last time we had this conversation, the conclusion was that simply
>> 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”.

+1.

- Shiz
Leonardo Arena <rnalrd@gmail.com>
Details
Message ID
<CAGG_d8D31EqCwFvBSQJSrqgYidWrypfZT1yeyK0wnZQL3keh9w@mail.gmail.com>
In-Reply-To
<53F16841-6ABC-4887-AC36-F6EE20010CAE@shiz.me> (view parent)
DKIM signature
missing
Download raw message
On Fri, Apr 9, 2021 at 11:25 AM Shiz <hi@shiz.me> wrote:

>
>
> > On 9 Apr 3 Reiwa, at 09:29, Nico Schottelius <
> nico.schottelius@ungleich.ch> wrote:
> >
> >
> > Good morning,
> >
> >
> > Ariadne Conill <ariadne@dereferenced.org> writes:
> >> On Fri, 9 Apr 2021, Zach van Rijn wrote:
> >>
> >>> 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:
> >>
> >> The last time we had this conversation, the conclusion was that simply
> >> 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”.
>
> +1.
>
> - Shiz
>
>
+1

/eo
Konstantin Kulikov <k.kulikov2@gmail.com>
Details
Message ID
<CAD+eXGTYOG19BTeNnLZ22c-kEy+hH_RKxwR6E+jVHrQP0xf3XQ@mail.gmail.com>
In-Reply-To
<3824aef2-8af2-d33a-47e3-c7c66bd6615e@dereferenced.org> (view parent)
DKIM signature
missing
Download raw message
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.

On Fri, Apr 9, 2021 at 5:31 AM 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.
>
> ## 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
Bart Ribbers <bribbers@disroot.org>
Details
Message ID
<2865634.x7l71cJiAP@spaceblade>
In-Reply-To
<CAD+eXGTYOG19BTeNnLZ22c-kEy+hH_RKxwR6E+jVHrQP0xf3XQ@mail.gmail.com> (view parent)
DKIM signature
missing
Download raw message
Hi,

On Friday, 9 April 2021 13:03:26 CEST Konstantin Kulikov wrote:
> 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.

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.

> 
> On Fri, Apr 9, 2021 at 5:31 AM 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.
> > 
> > ## 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

Bart
Francesco Colista <fcolista@alpinelinux.org>
Details
Message ID
<7a7d9e02aa8ace5183aa9d994e282558@alpinelinux.org>
In-Reply-To
<53F16841-6ABC-4887-AC36-F6EE20010CAE@shiz.me> (view parent)
DKIM signature
missing
Download raw message
9 aprile 2021 11:23, "Shiz" <hi@shiz.me> wrote:

>> 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”.
> 
> +1.
> 

+1 fpr Alpine 4

.: Francesco Colista
.: Alpine Linux Core Dev Team
Details
Message ID
<20210409160505.52ac106b@ncopa-desktop.lan>
In-Reply-To
<3824aef2-8af2-d33a-47e3-c7c66bd6615e@dereferenced.org> (view parent)
DKIM signature
missing
Download raw message
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
Jakub Jirutka <jakub@jirutka.cz>
Details
Message ID
<47f0dcd6-66e7-a369-1ea8-1f32af528cc0@jirutka.cz>
In-Reply-To
<20210409160505.52ac106b@ncopa-desktop.lan> (view parent)
DKIM signature
missing
Download raw message
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.

On 4/9/21 4:05 PM, Natanael Copa wrote:
> 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
> 
Rasmus Thomsen <oss@cogitri.dev>
Details
Message ID
<53233ba11e9a869706b24619f511ef15b035a8c5.camel@cogitri.dev>
In-Reply-To
<20210409160505.52ac106b@ncopa-desktop.lan> (view parent)
DKIM signature
missing
Download raw message
Hello,

On Fri, 2021-04-09 at 16:05 +0200, Natanael Copa wrote:
> 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.
> 

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

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

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
Details
Message ID
<CAAO3vZ8GMFuchKEF6qa4BA9yY6+QD6-uCaXCqqSwVOfH5MSHUQ@mail.gmail.com>
In-Reply-To
<20210409160505.52ac106b@ncopa-desktop.lan> (view parent)
DKIM signature
missing
Download raw message
+100.

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

пт, 9 квіт. 2021 о 17:08 Natanael Copa <ncopa@alpinelinux.org> пише:
>
> 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



-- 
Led.
Details
Message ID
<ef141bd0-542c-cc7a-1c3a-2b1d8763b0d3@gmail.com>
In-Reply-To
<3824aef2-8af2-d33a-47e3-c7c66bd6615e@dereferenced.org> (view parent)
DKIM signature
missing
Download raw message
 > 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.

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.
Details
Message ID
<5b29c07d-2bcb-9cc7-6e9-8353752f304e@dereferenced.org>
In-Reply-To
<CAAO3vZ8GMFuchKEF6qa4BA9yY6+QD6-uCaXCqqSwVOfH5MSHUQ@mail.gmail.com> (view parent)
DKIM signature
missing
Download raw message
Hi,

On Fri, 9 Apr 2021, Led wrote:

> +100.
>
> It looks like some are bored and they are trying to bury another
> 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
Tyler G. Sherrard <tyler@c705.be>
Details
Message ID
<KtRKNIvC2lsPRT2ZkGHwnPJAw9PRaPzpLmMX4qq6HVZ9GiEUSt94mhxBrtWQBCFW752AYC1aD0PJpZFms62_OaxXq-b-hTq1BBioaCIQUVk=@c705.be>
In-Reply-To
<53233ba11e9a869706b24619f511ef15b035a8c5.camel@cogitri.dev> (view parent)
DKIM signature
missing
Download raw message
+1 for this


>
> 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
>
Details
Message ID
<40ea7dd-b176-e635-c95b-64f9a969dcd4@dereferenced.org>
In-Reply-To
<47f0dcd6-66e7-a369-1ea8-1f32af528cc0@jirutka.cz> (view parent)
DKIM signature
missing
Download raw message
Hi,

On Fri, 9 Apr 2021, Jakub Jirutka wrote:

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

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

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

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
Details
Message ID
<YHCb8KIjvtcvl3pU@alpha>
In-Reply-To
<CAAO3vZ8GMFuchKEF6qa4BA9yY6+QD6-uCaXCqqSwVOfH5MSHUQ@mail.gmail.com> (view parent)
DKIM signature
missing
Download raw message
On Fri, Apr 09, 2021 at 06:05:40PM +0300, Led wrote:
> +100.
> 
> It looks like some are bored and they are trying to bury another
> 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
Marcus Rohrmoser <Marcus@Rohrmoser.name>
Details
Message ID
<BD89464F-203F-4832-99A4-C404B3B0D218@Rohrmoser.name>
In-Reply-To
<20210409160505.52ac106b@ncopa-desktop.lan> (view parent)
DKIM signature
missing
Download raw message
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)
Details
Message ID
<20210412121241.2fb279c1@ncopa-desktop.lan>
In-Reply-To
<5b29c07d-2bcb-9cc7-6e9-8353752f304e@dereferenced.org> (view parent)
DKIM signature
missing
Download raw message
On Fri, 9 Apr 2021 11:29:25 -0600 (MDT)
Ariadne Conill <ariadne@dereferenced.org> wrote:

> Hi,
> 
> On Fri, 9 Apr 2021, Led wrote:
> 
> > +100.
> >
> > It looks like some are bored and they are trying to bury another
> > 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

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
Details
Message ID
<87y2dng4sr.fsf@ungleich.ch>
In-Reply-To
<20210412121241.2fb279c1@ncopa-desktop.lan> (view parent)
DKIM signature
missing
Download raw message
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".


Natanael Copa <ncopa@alpinelinux.org> writes:

> On Fri, 9 Apr 2021 11:29:25 -0600 (MDT)
> Ariadne Conill <ariadne@dereferenced.org> wrote:
>
>> Hi,
>>
>> On Fri, 9 Apr 2021, Led wrote:
>>
>> > +100.
>> >
>> > It looks like some are bored and they are trying to bury another
>> > 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
>
> 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


--
Sustainable and modern Infrastructures by ungleich.ch
Reply to thread Export thread (mbox)