X-Original-To: alpine-devel@lists.alpinelinux.org Received: from mx1.tetrasec.net (mx1.tetrasec.net [74.117.190.25]) by lists.alpinelinux.org (Postfix) with ESMTP id C385EF855C6 for ; Thu, 4 Apr 2019 11:30:07 +0000 (UTC) Received: from mx1.tetrasec.net (mail.local [127.0.0.1]) by mx1.tetrasec.net (Postfix) with ESMTP id 810599E1E83; Thu, 4 Apr 2019 11:30:07 +0000 (UTC) Received: from ncopa-desktop.copa.dup.pw (67.63.200.37.customer.cdi.no [37.200.63.67]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: alpine@tanael.org) by mx1.tetrasec.net (Postfix) with ESMTPSA id 733509E1CA6; Thu, 4 Apr 2019 11:30:06 +0000 (UTC) Date: Thu, 4 Apr 2019 13:30:01 +0200 From: Natanael Copa To: C H Cc: alpine-devel@lists.alpinelinux.org Subject: Re: [alpine-devel] Should we drop armhf (armv6) support with 3.10 release? Message-ID: <20190404133001.1822723d@ncopa-desktop.copa.dup.pw> In-Reply-To: References: <20190404112525.4b04fdeb@ncopa-desktop.copa.dup.pw> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-alpine-linux-musl) X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Thu, 4 Apr 2019 07:06:30 -0400 C H wrote: > On Thu, Apr 4, 2019, 06:27 Leonardo Arena wrote: > > > > > On Thu, Apr 4, 2019 at 11:25 AM Natanael Copa > > wrote: > > > >> Hi, > >> > >> I wonder if can drop armhf (armv6) support with the 3.10 release, now > >> that we have armv7? > >> > >> > > +1 > > > > /eo > > > > I'm new 'round here, but that might be sufficient motivation for a 4.0 > release, especially coupled with the other proposed changes -- GCC 9, maybe > the python refactor, etc.. > > Is there precedent for rolling major version numbers? > We changed from alpine 1.x to 2.x when there was an ABI breaking change in uClibc. We changed from alpine 2.x to 3.x when we moved from uClibc to musl libc. In both those occasions an upgrade meant a full re-install. Older packages would not work with new release. Now, in practice, we do full reinstall every release anyway. `apk upgrade -U -a` will replace all packages, so major version number roll does not matter that much. We have been talking about do 4.0 release with apk-tools 3.0, which will have incompatible database format. That project is stalled though. *If* we would ever switch to GNU libc, that would qualify for major version number roll. But there are no plans for that, and will hopefully never be. So basically, the idea with use 3.10 was that we follow something similar to semver, but I don't have strong opinion there. I think "4.0" looks better than "3.10". On the other hand "3.11" can be fun. Alpine Linux 3.11 for workgroups... -nc --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ---