From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tanguy Le Carrour Subject: Re: Questions about packaging Date: Mon, 14 Oct 2019 09:51:54 +0200 Message-ID: <20191014075154.glbillit5hu7p6vb@rafflesia> References: <20191009095633.qlhnq2yvtp7dbrrf@rafflesia> <20191010024127.1da7c86d@scratchpost.org> <20191011074200.azkyt4mufjazbuj6@rafflesia> <20191012124116.6f842667@scratchpost.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:48973) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iJv95-0000HR-73 for guix-devel@gnu.org; Mon, 14 Oct 2019 03:52:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iJv93-0001Ih-Qf for guix-devel@gnu.org; Mon, 14 Oct 2019 03:51:59 -0400 Received: from relay5-d.mail.gandi.net ([217.70.183.197]:55725) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iJv93-0001Ht-K8 for guix-devel@gnu.org; Mon, 14 Oct 2019 03:51:57 -0400 Content-Disposition: inline In-Reply-To: <20191012124116.6f842667@scratchpost.org> 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: Danny Milosavljevic Cc: Guix Hi Danny Le 10/12, Danny Milosavljevic a écrit : > On Fri, 11 Oct 2019 09:42:00 +0200 > Tanguy Le Carrour wrote: > > > Le 10/10, Danny Milosavljevic a écrit : > > > > 1) Updating a package > > > > So I would have to update python-cachecontrol from 0.11.6 to 0.12.5. > > > > Should I create a python-cachecontrol-0.11.6 and fix all the packages > > > > that depend on it? Only the one that would break? > > > > > > The latter. That's one of the things we do at Guix but I would not do at work. > > > > OK. I'll do that! > > My next question would be "when would someone create a versionned package name?" > > If it's unavoidable. One of the reasons is that we don't want to increase our > maintenance and testing burden unduly and thus would not want 453 versions of > the same package available at the same time (chances are that some combination > would not have been tested and/or not work). > > But there are professional engineering standards which allow you to specify > which versions of thing A can go with which other versions of thing B. > > The most well-known type of that in software is semantic versioning. > > So it depends on what kind of versioning scheme the project/package in question > uses. If it does use semantic versioning or similar then packages which have > changes making it fundamentally incompatible with what came before will increase > their major version, basically making that an independent package (Debian for > example has the major version in that sense in their package NAMES for > libraries). Shame on me! I'm perfectly aware of SemVer [1], it's "just" that I mixed up the problem with python-cachecontrol and the other one with pytest that was shadowed by python-cachecontrol! So, yes, there is no version problem going from 0.11.6 to 0.12.5, has it's only a change of minor version. The pytest problem that I did not mention was a major change, with deprecation of some hooks (pytest_namespace). In Guix, we have Pytest 4.4.2, but the latest release is 5.2.1. In that case, would it make sense to define a new "versionned" public variable for python-pytest? Would I create python-pytest5? Or would I rename python-pytest to python-pytest4 and add python-pytest for Pytest 5? In this later case, would I have to "fix" all the packages that were using python-pytest?! [1]: https://semver.org/ > Eventually in some years, there will be no users (other packages) of Python 2 > anymore. Once that comes to pass we can drop Python 2. What we can't do is > replace Python 2 by Python 3 in those user packages--it would break them. "in some years" will be next year [2]. But I guess Python2 will still be around for some more years. [2]: https://www.python.org/dev/peps/pep-0373/ Thanks again for the time you spent clarifying all this for me! -- Tanguy