From mboxrd@z Thu Jan 1 00:00:00 1970 From: Danny Milosavljevic Subject: Package API compatibility and guix package variable names Date: Wed, 27 Jul 2016 17:54:31 +0200 Message-ID: <20160727175431.35fc6326@scratchpost.org> References: <20160719205719.20769-1-rekado@elephly.net> <87y44wdr1f.fsf@elephly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:43252) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bSRAT-0002pF-Cn for guix-devel@gnu.org; Wed, 27 Jul 2016 11:54:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bSRAO-00022h-ES for guix-devel@gnu.org; Wed, 27 Jul 2016 11:54:44 -0400 Received: from dd1012.kasserver.com ([85.13.128.8]:56951) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bSRAO-00022D-7j for guix-devel@gnu.org; Wed, 27 Jul 2016 11:54:40 -0400 In-Reply-To: <87y44wdr1f.fsf@elephly.net> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: guix-devel > > Shouldn't this be allegro-5 since there is already an allegro-4? =20 >=20 > I want the =E2=80=9Callegro=E2=80=9D variable to simply hold the latest v= ersion of > allegro. If ever there=E2=80=99s a need to clarify (e.g. because we need= to > keep around the last of the 5.x series when 6.x comes out) we can change > the name then. As far as I can see that=E2=80=99s been our approach for = some > other packages, too, most prominently =E2=80=9Cpython=E2=80=9D. In my humble opinion it would best if there was an "allego-5.0" and an "all= egro" variable, with the "allegro" variable not being referenced by any oth= er package (they would reference "allegro-5.0" instead - or whatever major = API version they need, for example "allegro-5.2"). This way we wouldn't have to update half of all package specs after they br= eak just because a new incompatible version came out. I think the way it was done for Python3 in Guix is wrong. On the other hand= , the way it was done for Python2 in Guix was exactly right. What happens when a new (incompatible) Python4 comes out? Patch all the Pyt= hon modules package specs there are? The only reason we can get away with i= t for Python is because they only do breaking change in the language every = five years. This is something Debian got right - have the (API) version as suffix as pa= rt of the name. The "allegro" metapackage is purely a user convenience (of questionable ben= efit). If something becomes incompatible, its name should change.