[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Questions about packaging
From: |
Tanguy Le Carrour |
Subject: |
Re: Questions about packaging |
Date: |
Mon, 14 Oct 2019 09:51:54 +0200 |
User-agent: |
NeoMutt/20180716 |
Hi Danny
Le 10/12, Danny Milosavljevic a écrit :
> On Fri, 11 Oct 2019 09:42:00 +0200
> Tanguy Le Carrour <address@hidden> 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
- Questions about packaging, Tanguy Le Carrour, 2019/10/09
- Re: Questions about packaging, Danny Milosavljevic, 2019/10/09
- Re: Questions about packaging, Tanguy Le Carrour, 2019/10/11
- Re: Questions about packaging,
Tanguy Le Carrour <=
- Re: Questions about packaging, Marius Bakke, 2019/10/18
- Re: Questions about packaging, Tanguy Le Carrour, 2019/10/21
- Re: Questions about packaging, Gábor Boskovits, 2019/10/21
- Re: Questions about packaging, Marius Bakke, 2019/10/23