Received: from cogitri.dev (cogitri.dev [207.180.226.74]) by nld3-dev1.alpinelinux.org (Postfix) with ESMTPS id 190D7782E12 for <~alpine/devel@lists.alpinelinux.org>; Fri, 9 Apr 2021 14:57:59 +0000 (UTC) Message-ID: <53233ba11e9a869706b24619f511ef15b035a8c5.camel@cogitri.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cogitri.dev; s=mail; t=1617980277; bh=ftg4uGc4m0xHpxkaS/SXB5XHm3mHYu3Y9/74rFdcjFE=; h=Subject:From:To:Cc:In-Reply-To:References; b=XzoQQX4k11fbmaCaXkilLq8rlAmYVlKLBGkVtlQwnuy2Gu93VkWjIWWq/c/mYZ0mL YHSeEaBweRYC1WmY0rBibGTRcdnv7r9sU2gBSeHXa9gFLjwCfxdp86ANpueKa6nU4J 1i/ZRev81UYQXTpt529hikpu5ZMlpQ4cXqZ6XRfvQlfLgO0DBBcmif4128XDKDC4K2 DbHrlUIA4eYGcJrrurxzGWs11pfVNW2Bo1rsJklanZ/picF3yUvmCj00MuF2kRSwDO 0hf6uFvYCklOJDtsXdnaAzswaD9T9xGkwPpMq8pTLsCJUztBSG4jEPgyBYtcUEadds eYX11y/MFFqbQ== Subject: Re: [3.15] System change proposal: rename the Alpine 3.15 release to Alpine 15 From: Rasmus Thomsen To: Natanael Copa , Ariadne Conill Cc: ~alpine/devel@lists.alpinelinux.org Date: Fri, 09 Apr 2021 16:57:54 +0200 In-Reply-To: <20210409160505.52ac106b@ncopa-desktop.lan> References: <3824aef2-8af2-d33a-47e3-c7c66bd6615e@dereferenced.org> <20210409160505.52ac106b@ncopa-desktop.lan> Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-how/SJnSiNQyqeQQILq+" Mime-Version: 1.0 --=-how/SJnSiNQyqeQQILq+ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 wrote: >=20 > > Hello, > >=20 > > Alpine has traditionally used the major version to represent the > > current=20 > > ABI version the system uses.=C2=A0 For example, Alpine 1.x was uClibc > > without=20 > > NPTL, Alpine 2.x was uClibc with NPTL and Alpine 3.x is based on > > musl. > >=20 > > With the current ABI being evergreen, and our having moved past the > > 3.14=20 > > release, it no longer makes sense to keep the 3.x designation.=C2=A0 > > When this=20 > > was previously proposed, the primary request was to postpone this=20 > > discussion until after Alpine 3.14 release.=C2=A0 With the Alpine 3.14 > > release=20 > > imminent, I believe now is a time to bring this up again. > >=20 > > An argument could have been made to jump to Alpine 4.x with apk- > > tools 3,=20 > > but we have decided to implement apk-tools 3 out in a way that is=20 > > non-disruptive.=C2=A0 So that argument is now moot, as well. >=20 > 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? >=20 > The apk tools 3 may also be a better time to switch to 4.x, because > it > will change the database format. >=20 +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 > >=20 > > As the `3.` part of the version is now effectively meaningless, it > > is=20 > > helpful to downstream consumers of Alpine to have a simplified > > versioning=20 > > scheme.=C2=A0 For example, postmarketOS can say "based on Alpine 15" > > instead of=20 > > "Alpine 3.15" which sounds better. > >=20 > > Yes, to be brutally honest, this is an entirely marketing-related > > thing,=20 > > and there is no technical benefit either way.=C2=A0 However, this > > versioning=20 > > scheme is more aligned with other Linux distributions. >=20 > 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 > =C2=A0 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 > =C2=A0 don't we call it 2021.10.x? or 4.x?", "why dont we do real semver?= " > =C2=A0 how do we deal with patch releases? > - regardless of what we change it to, there will be people > complaining. > =C2=A0 changes are always painful for someone. >=20 > > ## Implementation Plan > >=20 > > Set the version of `alpine-base` to `15_alphaXXXXXXXX` instead of=20 > > `3.15_alphaXXXXXXXX`. > >=20 > > ## Contingency Plan > >=20 > > If we decide we don't want to do this, we just downgrade `alpine- > > base`=20 > > back to `3.15_alphaXXXXXXXX`. > >=20 > > Ariadne >=20 > 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. >=20 > Or build a better building infra. >=20 > Or write a better test suite for abuild. >=20 > There many other things that I'd like to prioritize over a version > change. But that's just me I guess. >=20 > -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 --=-how/SJnSiNQyqeQQILq+ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEErepJabCshwIJ3OXBERUkFRgVTqYFAmBwa3IACgkQERUkFRgV TqYZphAAjeA8wOovp1JCvitkZmVyOCKdJ9THgGsK3k0t2teoDJYytsN1difjCsXj iEXI/O5YfRng1dIbpFwyH8M5FhyJ9VE3fAsvdTXTkhjKyuSf+kg6MzteNcTfNmf/ AsQ6Tiu6KH3ygPWO8A4sh7Yovmr94SEq5nt6szSgEfbqTaPA5hiZBiMSxlJzXXjO ejZfTHNx9XrKLsgJOqz28XHeeSy5HoMT6iShA9l19MabW92N+b6OWNIlozWd+uKG 6GLyDts1IaX7mDIWF7QnARDC0x2waswZEqVOLc1U7xT+kUMozXNcZJ6iXCys7xgQ Dt2dlwzFCjzbvrdcQYydOCT+fMemw2XfyuWX8DaFz9W7GORFa+lweHYLm3XvuKrJ l2ZFdGG5BW7tiaAIkG378Dfv8b3fXBBg6NRbEypCu9w8NRhOxQq7qGO7B6uTnOPr X2oPBw2EWZxH7/G7tUViFdpNZBTmPF3JBBVodAU77IAWGKtAmdY25QgPmj9fOnL5 z3TMVl0eNM5/xPdqi2QVNlHhQ+TWOXuxI3Q4YkGWe5y7fhVI6v+BtsjmbFWUaGj1 0ETZHTrQWXvZ7HTTO9KrX/OuZnYkdM4dPPH7IvYYzHzOVA5RZQMXXeAquScfH7Lt tgojCqqoNeMdHgMacarrt2spfZolGMBAXm9Aci5Jt6O09zrzimY= =Fn7B -----END PGP SIGNATURE----- --=-how/SJnSiNQyqeQQILq+--