Re: [Distutils] PEP 386 and git versioning scheme
On 28/01/2013 18:21, Manlio Perillo wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi. In a project I'm working on, I use git, and I'm trying to follow the versioning scheme used by the git project (since it is very pratical). To summarize, git version is generated from the output of git describe command, replacing the '-' character with '.'. git describe returns a string formed by using the most recent tag (e.g. 1.8.1, 1.8.1.rc1), and adding the number of revisions after that tag, and the short ID of the current revision (e.g v1.8.1-301-ga0df26f). So, a version may be something like: v1.8.1.301.ga0df26f It seems that this versioning scheme is not compatible with PEP 386 new versioning scheme. Is this true? I hope not, can someone comment on this? We need to deal with hashes-in-versions as both Git and Mercurial are likely to have this... cheers, Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 386 and git versioning scheme
On 17 Feb 2013 05:11, Chris Withers ch...@simplistix.co.uk wrote: On 28/01/2013 18:21, Manlio Perillo wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi. In a project I'm working on, I use git, and I'm trying to follow the versioning scheme used by the git project (since it is very pratical). To summarize, git version is generated from the output of git describe command, replacing the '-' character with '.'. git describe returns a string formed by using the most recent tag (e.g. 1.8.1, 1.8.1.rc1), and adding the number of revisions after that tag, and the short ID of the current revision (e.g v1.8.1-301-ga0df26f). So, a version may be something like: v1.8.1.301.ga0df26f It seems that this versioning scheme is not compatible with PEP 386 new versioning scheme. Is this true? I hope not, can someone comment on this? We need to deal with hashes-in-versions as both Git and Mercurial are likely to have this... It's deliberately incompatible - we don't want installers (for wheel in particular) to have to guess about the version ordering for every versioning scheme on the planet. However, I now plan to add a Private-Version field which will be an arbitrary version label. So projects will be free to use whatever internal versioning scheme they want, so long as they (or, more accurately, their distribution tools) also translate it to a standard version for use with version specifiers. That's actually already the case, but the new field will make it clearer and more transparent. Cheers, Nick. cheers, Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 386 and git versioning scheme
On Sat, Feb 16, 2013 at 8:26 PM, Nick Coghlan ncogh...@gmail.com wrote: On 17 Feb 2013 05:11, Chris Withers ch...@simplistix.co.uk wrote: On 28/01/2013 18:21, Manlio Perillo wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi. In a project I'm working on, I use git, and I'm trying to follow the versioning scheme used by the git project (since it is very pratical). To summarize, git version is generated from the output of git describe command, replacing the '-' character with '.'. git describe returns a string formed by using the most recent tag (e.g. 1.8.1, 1.8.1.rc1), and adding the number of revisions after that tag, and the short ID of the current revision (e.g v1.8.1-301-ga0df26f). So, a version may be something like: v1.8.1.301.ga0df26f It seems that this versioning scheme is not compatible with PEP 386 new versioning scheme. Is this true? I hope not, can someone comment on this? We need to deal with hashes-in-versions as both Git and Mercurial are likely to have this... It's deliberately incompatible - we don't want installers (for wheel in particular) to have to guess about the version ordering for every versioning scheme on the planet. However, I now plan to add a Private-Version field which will be an arbitrary version label. So projects will be free to use whatever internal versioning scheme they want, so long as they (or, more accurately, their distribution tools) also translate it to a standard version for use with version specifiers. That's actually already the case, but the new field will make it clearer and more transparent. Cheers, Nick. I would think of a git^Wmercurial ID used as the last version component a non-sorting string. It is never intended to actually break a tie between two versions; if you do wind up using it to sort then you are in trouble (two people published a development version that happened to be n commits above the last tag...). The last component only tells you that 1.8.1.301.x and 1.8.1.301.y are not the same version, not that one should be greater or less than the other. I am OK with the PEP 386 restrictions. You can convert git's hex id to decimal ;-) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 386 and git versioning scheme
On Sun, Feb 17, 2013 at 11:56 AM, Daniel Holth dho...@gmail.com wrote: I would think of a git^Wmercurial ID used as the last version component a non-sorting string. It is never intended to actually break a tie between two versions; if you do wind up using it to sort then you are in trouble (two people published a development version that happened to be n commits above the last tag...). The last component only tells you that 1.8.1.301.x and 1.8.1.301.y are not the same version, not that one should be greater or less than the other. I agree - that's why I'm going to propose Private-Version as an *unordered* version label (although the project itself may have a way to order them), while Version will be the *ordered* version label actually used by automated tools. Tools can then use the .devN suffix to map arbitrary pre-release version schemes (including semantic versioning) to the standard orderable scheme. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] PEP 386 and git versioning scheme
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi. In a project I'm working on, I use git, and I'm trying to follow the versioning scheme used by the git project (since it is very pratical). To summarize, git version is generated from the output of git describe command, replacing the '-' character with '.'. git describe returns a string formed by using the most recent tag (e.g. 1.8.1, 1.8.1.rc1), and adding the number of revisions after that tag, and the short ID of the current revision (e.g v1.8.1-301-ga0df26f). So, a version may be something like: v1.8.1.301.ga0df26f It seems that this versioning scheme is not compatible with PEP 386 new versioning scheme. Is this true? Thanks Manlio Perillo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlEGwaYACgkQscQJ24LbaUT1dQCcD0iaA7NSMJIIXX907VQUyoOH LGQAnixPvzjCfSRaWAONy+cVrDPjXpoK =ooSg -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
