unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Tanguy Le Carrour <tanguy@bioneland.org>
To: Danny Milosavljevic <dannym@scratchpost.org>
Cc: Guix <guix-devel@gnu.org>
Subject: Re: Questions about packaging
Date: Mon, 14 Oct 2019 09:51:54 +0200	[thread overview]
Message-ID: <20191014075154.glbillit5hu7p6vb@rafflesia> (raw)
In-Reply-To: <20191012124116.6f842667@scratchpost.org>

Hi Danny


Le 10/12, Danny Milosavljevic a écrit :
> On Fri, 11 Oct 2019 09:42:00 +0200
> Tanguy Le Carrour <tanguy@bioneland.org> 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

  parent reply	other threads:[~2019-10-14  7:52 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-09  9:56 Questions about packaging Tanguy Le Carrour
2019-10-10  0:41 ` Danny Milosavljevic
2019-10-11  7:42   ` Tanguy Le Carrour
2019-10-12 10:41     ` Danny Milosavljevic
2019-10-12 10:49       ` Danny Milosavljevic
2019-10-14  7:53         ` Tanguy Le Carrour
2019-10-14  7:51       ` Tanguy Le Carrour [this message]
2019-10-18 17:16         ` Marius Bakke
2019-10-21  9:23           ` Tanguy Le Carrour
2019-10-21  9:34             ` Gábor Boskovits
2019-10-23 18:10             ` Marius Bakke

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191014075154.glbillit5hu7p6vb@rafflesia \
    --to=tanguy@bioneland.org \
    --cc=dannym@scratchpost.org \
    --cc=guix-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).