So after creating, say, version 0.3.1, I always mark a package as 0.3.2dev. But this is annoying, you might never create a version 0.3.2 (e.g., 0.4 might be the next level). So, it would be better to use something like 0.3.1~dev. What is considered best practice for this? Ideally something that works with both Setuptools and the upcoming Distribute version spec. -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker
On Thu, Oct 8, 2009 at 5:41 PM, Ian Bicking <ianb@colorstudy.com> wrote:
So after creating, say, version 0.3.1, I always mark a package as 0.3.2dev. But this is annoying, you might never create a version 0.3.2 (e.g., 0.4 might be the next level). So, it would be better to use something like 0.3.1~dev. What is considered best practice for this? Ideally something that works with both Setuptools and the upcoming Distribute version spec.
I like using a version of "0" on my project trunks. I set the release version on release tags. I really wish there was a special version (or a version pattern) that indicated that something is a development version *only* and can't be released. I don't think best practices have been established. Jim -- Jim Fulton
On Thu, Oct 8, 2009 at 5:06 PM, Jim Fulton <jim@zope.com> wrote:
On Thu, Oct 8, 2009 at 5:41 PM, Ian Bicking <ianb@colorstudy.com> wrote:
So after creating, say, version 0.3.1, I always mark a package as 0.3.2dev. But this is annoying, you might never create a version 0.3.2 (e.g., 0.4 might be the next level). So, it would be better to use something like 0.3.1~dev. What is considered best practice for this? Ideally something that works with both Setuptools and the upcoming Distribute version spec.
I like using a version of "0" on my project trunks. I set the release version on release tags. I really wish there was a special version (or a version pattern) that indicated that something is a development version *only* and can't be released. I don't think best practices have been established.
It would be nice if there was a sense of branches. E.g., if I fork a project, say setuptools-0.6c3, I could make setuptools-ianb-0.6c3 and someone could install, say, setuptools==ianb, getting whatever was the newest version of my branch. But ianb-0.6c3 wouldn't be comparable to any other version except versions on that branch. Though once installed it would satisfy a generic "setuptools" requirement. This could be used for a dev branch as well, which would satisfy a requirement but not be considered part of the same version series as the stable releases. -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker
2009/10/9 Jim Fulton <jim@zope.com>:
I like using a version of "0" on my project trunks. I set the release version on release tags. I really wish there was a special version (or a version pattern) that indicated that something is a development version *only* and can't be released. I don't think best practices have been established.
Some of the projects I work on have a setup.cfg which says it's a development version. If you then build it you get the horrid package version with r34567654 in it, and you notice that you shouldn't release it. I then usually delete it in the tag. I guess that's the "official" version of setting the the version to 0. I have no idea if something is better or worse. :) -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
On Thursday,2009-10-08, at 15:41 , Ian Bicking wrote:
So after creating, say, version 0.3.1, I always mark a package as 0.3.2dev. But this is annoying, you might never create a version 0.3.2 (e.g., 0.4 might be the next level).
So, it would be better to use something like 0.3.1~dev. What is considered best practice for this? Ideally something that works with both Setuptools and the upcoming Distribute version spec.
What we do in the Tahoe-LAFS project is we don't count down to a future version, we only count up from a past version. This is also what Twisted does (no coincidence -- we probably got the idea from them). So the most recent release of Tahoe-LAFS was 1.5.0. The next time we committed a patch to our darcs repository, it automatically got the version number 1.5.0-r4040. (The automation to do this is our own implementation -- darcsver [1], but it produces the same kind of output as setuptools's builtin svn integration and Twisted's own svn integration does.) The current snapshot build of Tahoe-LAFS is numbered 1.5.0-r4073, and eventually we will have one numbered something like 1.5.0-r4123, and then the very next version will be 1.6.0. The next version after that will be 1.6.0-r4125. This means that we don't have version numbers with things like "beta" in their name. The most recent time that we had a beta was, I think, Tahoe-LAFS 1.4.1-r4021. We just announced on our mailing list "Hey everybody, we're ready to make a new release! Please try the current version (1.4.1-r4021) and tell us if it works for you!". Regards, Zooko [1] http://pypi.python.org/pypi/darcsver
On Thu, Oct 8, 2009 at 6:40 PM, Zooko Wilcox-O'Hearn <zooko@zooko.com> wrote:
What we do in the Tahoe-LAFS project is we don't count down to a future version, we only count up from a past version. This is also what Twisted does (no coincidence -- we probably got the idea from them).
To clarify: that means that a beta for 2.0.0 might have a version of 1.6.3-r4321? -- Benji York Senior Software Engineer Zope Corporation
On 12:25 pm, benji@zope.com wrote:
On Thu, Oct 8, 2009 at 6:40 PM, Zooko Wilcox-O'Hearn <zooko@zooko.com> wrote:
What we do in the Tahoe-LAFS project is we don't count down to a future version, we only count up from a past version. �This is also what Twisted does (no coincidence -- we probably got the idea from them).
To clarify: that means that a beta for 2.0.0 might have a version of 1.6.3-r4321?
I'm not sure how zooko does this for Tahoe, but with Twisted (with which we don't do "betas" but we do do "pre-releases") if we were to start getting ready for 2.0.0, then we would create a release branch and change the version in that release branch to 2.0.0pre1. This, of course, complicates the matter. :) I don't think anyone has considered how our pre-release version numbers sort compared to the rest of our version numbers. After 2.0.0 final is released, we merge the release branch back into trunk, changing the trunk version to 2.0.0-r54321. Jean-Paul
exarkun@twistedmatrix.com wrote:
I'm not sure how zooko does this for Tahoe, but with Twisted (with which we don't do "betas" but we do do "pre-releases") if we were to start getting ready for 2.0.0, then we would create a release branch and change the version in that release branch to 2.0.0pre1. This, of course, complicates the matter. :) I don't think anyone has considered how our pre-release version numbers sort compared to the rest of our version numbers. After 2.0.0 final is released, we merge the release branch back into trunk, changing the trunk version to 2.0.0-r54321.
I beg you to make sure that whatever ends up in the python core to do with sorting and comparing version numbers takes your use case into account. I like the way you do things :-) (rare I say that about Twisted ;-) ) I'm -1 on "0" or any other special-case singleton version number... I'm +1 on the branch having a version of 1.6.3~dev after 1.6.3 has been released, and I like 2.0.0pre1 too :-) Moreover, I wish we could just get a bdfl pronouncement on something that works for everyone and get on with it :-D Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk
Andrew Straw wrote:
Chris Withers wrote:
I'm +1 on the branch having a version of 1.6.3~dev after 1.6.3 has been released, and I like 2.0.0pre1 too :-) I'm -1 on "~" meaning afterwards, because in Debian package versions it means the exact opposite.
I'm neutral on the exact spelling, I just like the idea :-) Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk
On Fri, Oct 09, 2009 at 01:24:50PM -0000, exarkun@twistedmatrix.com wrote:
On 12:25 pm, benji@zope.com wrote:
On Thu, Oct 8, 2009 at 6:40 PM, Zooko Wilcox-O'Hearn <zooko@zooko.com> wrote:
What we do in the Tahoe-LAFS project is we don't count down to a future version, we only count up from a past version. ?This is also what Twisted does (no coincidence -- we probably got the idea from them).
To clarify: that means that a beta for 2.0.0 might have a version of 1.6.3-r4321?
I'm not sure how zooko does this for Tahoe, but with Twisted (with which we don't do "betas" but we do do "pre-releases") if we were to start getting ready for 2.0.0, then we would create a release branch and change the version in that release branch to 2.0.0pre1. This, of course, complicates the matter. :) I don't think anyone has considered how our pre-release version numbers sort compared to the rest of our version numbers. After 2.0.0 final is released, we merge the release branch back into trunk, changing the trunk version to 2.0.0-r54321.
The pre-release would become 2.0.0.dev1 in the proposed PEP386 spec I guess, however the suggest_rational_version() function suggests otherwise:
verlib.suggest_rational_version('2.0.0pre1') '2.0.0c1'
It interprets your version string as a "release candidate" version, which it actually might be given that you gave it it a number of "1" and not some longer revision-control based one. Regards Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org
On Friday,2009-10-09, at 6:25 , Benji York wrote:
On Thu, Oct 8, 2009 at 6:40 PM, Zooko Wilcox-O'Hearn <zooko@zooko.com> wrote:
What we do in the Tahoe-LAFS project is we don't count down to a future version, we only count up from a past version. This is also what Twisted does (no coincidence -- we probably got the idea from them).
To clarify: that means that a beta for 2.0.0 might have a version of 1.6.3-r4321?
Yes, that's right. We haven't done this yet, but I suppose we could announce "the beta for 2.0.0" and give people 1.6.3-r4321 saying "This is the beta for 2.0.0.". What we've done so far is a little less formal. We say "Hey there are no more tickets open for 2.0.0 (see the issue tracker), so please everyone test the current version (1.6.3-r4321), and in about a week if there are no important new bugs discovered then we'll bump the version number to 2.0.0 and release it!". This is much like a beta but the word "beta" doesn't appear in the announcement. Regards, Zooko
On Thu, Oct 08, 2009 at 04:41:25PM -0500, Ian Bicking wrote:
So after creating, say, version 0.3.1, I always mark a package as 0.3.2dev. But this is annoying, you might never create a version 0.3.2 (e.g., 0.4 might be the next level). So, it would be better to use something like 0.3.1~dev. What is considered best practice for this? Ideally something that works with both Setuptools and the upcoming Distribute version spec.
The verlib [0] aka PEP 386 way as currently proposed is to use 0.3.1.post123 to do count away from releases (i.e. "post-releases"). Regards Floris [0] http://www.python.org/dev/peps/pep-0386/ -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org
Ian Bicking <ianb@colorstudy.com> writes:
So after creating, say, version 0.3.1, I always mark a package as 0.3.2dev.
Why not just mark it 0.3.2 during development, and change the version string in a later revision if warranted?
But this is annoying, you might never create a version 0.3.2 (e.g., 0.4 might be the next level).
So what? If there are revisions in your VCS that have a particular version string 0.3.2, you can look to the release log to see whether this revision is later than version 0.3 and earlier than version 0.4. What does it matter tha 0.3.2 was never actually released? Zooko Wilcox-O'Hearn <zooko@zooko.com> writes:
On Thursday,2009-10-08, at 15:41 , Ian Bicking wrote:
What is considered best practice for this? Ideally something that works with both Setuptools and the upcoming Distribute version spec.
What we do in the Tahoe-LAFS project is we don't count down to a future version, we only count up from a past version. This is also what Twisted does (no coincidence -- we probably got the idea from them).
That sounds eminently sensible and simple.
So the most recent release of Tahoe-LAFS was 1.5.0. The next time we committed a patch to our darcs repository, it automatically got the version number 1.5.0-r4040.
Right. If someone later decides that the version string should be incremented during development, they can do that; just so long as it only ever increases (and, by corrollary, that no-one increments the version string lightly).
This means that we don't have version numbers with things like "beta" in their name. The most recent time that we had a beta was, I think, Tahoe-LAFS 1.4.1-r4021. We just announced on our mailing list "Hey everybody, we're ready to make a new release! Please try the current version (1.4.1-r4021) and tell us if it works for you!".
I applaud this practice; I find it far more simple and comprehensible than special out-of-sequence keywords in version strings. -- \ “The man who is denied the opportunity of taking decisions of | `\ importance begins to regard as important the decisions he is | _o__) allowed to take.” —C. Northcote Parkinson | Ben Finney
On 2009-10-08, Ian Bicking <ianb@colorstudy.com> wrote:
So after creating, say, version 0.3.1, I always mark a package as 0.3.2dev. But this is annoying, you might never create a version 0.3.2 (e.g., 0.4 might be the next level). So, it would be better to use something like 0.3.1~dev. What is considered best practice for this? Ideally something that works with both Setuptools and the upcoming Distribute version spec.
a) Where's the annoyment exactly? It is easy to change and it's a release-time decision anyway. b) In a previous discussion on a zope mailinglist (about using '0' for this purpose, which was pretty much shot down for the zope toolkit because of the problems attached to it), someone mentioned adding '+svn' to the previous version number. So from 0.3.1 to 0.3.1+svn. Apparently that sorts it behind 0.3.1. You could try something like that. The poster mentioned it as a debian standard. Reinout -- Reinout van Rees - reinout@vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com "Military engineers build missiles. Civil engineers build targets"
Reinout van Rees wrote:
On 2009-10-08, Ian Bicking <ianb@colorstudy.com> wrote:
So after creating, say, version 0.3.1, I always mark a package as 0.3.2dev. But this is annoying, you might never create a version 0.3.2 (e.g., 0.4 might be the next level). So, it would be better to use something like 0.3.1~dev. What is considered best practice for this? Ideally something that works with both Setuptools and the upcoming Distribute version spec.
a) Where's the annoyment exactly? It is easy to change and it's a release-time decision anyway.
b) In a previous discussion on a zope mailinglist (about using '0' for this purpose, which was pretty much shot down for the zope toolkit because of the problems attached to it), someone mentioned adding '+svn' to the previous version number. So from 0.3.1 to 0.3.1+svn. Apparently that sorts it behind 0.3.1. You could try something like that. The poster mentioned it as a debian standard.
Reinout
I just caught the tail end of this thread so please excuse if you may have covered this. With regard to package version and release strings here is something that I have been using successfully that generates proper lexical package ordering for tarballs, debian (.deb) and redhat (.rpm) packaging. The same patterns should work just as well for any other packaging system: We use the following for the various VERSION-RELEASE strings: examples use: bzr as version control system but you can substitute hg, git, svn, rcs, or any other type of vcs rpm as packaging system Development: version="5.0.0" release="0.00012345" (where 00012345 is the revision number from your vcs in ZERO-PADDED FIELD OF 8) tarball: foo-5.0.0-0.00012345.tar.gz rpm: foo-5.0.0-0.00012345.noarch.rpm Alpha: version="5.0.0" release="0.alpha1.00123456" tarball: foo-5.0.0-0.alpha1.00123456.tar.gz rpm: foo-5.0.0-0.alpha1.00123456.noarch.rpm Beta: version="5.0.0" release="0.beta1.00234567" tarball: foo-5.0.0-0.beta1.00234567.tar.gz rpm: foo-5.0.0-0.beta1.00234567.noarch.rpm Release Candidate: version="5.0.0" release="0.rc1" tarball: foo-5.0.0-0.rc1.tar.gz rpm: foo-5.0.0-0.rc1.noarch.rpm Release Candidate code fix: version="5.0.0" release="0.rc1.00345678" tarball: foo-5.0.0-0.rc1.00345678.tar.gz rpm: foo-5.0.0-0.rc1.00345678.noarch.rpm Final Release: version="5.0.0" release="1" tarball: foo-5.0.0-1.tar.gz rpm: foo-5.0.0-1.noarch.rpm Final Release code fix: version="5.0.0" release="2" tarball: foo-5.0.0-2.tar.gz rpm: foo-5.0.0-2.noarch.rpm Notice that lexical ordering is proper in all cases. Even where the alpha, beta, rc pre-releases may be followed by a bug fix revision. The key is that all pre-releases (alpha, beta, etc.) have a release string starting with "0." and the first production release has a release string of "1". This is how the lexical ordering is kept for all packaging types (tarballs, rpm, deb). Regards, Gerry
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Reinout van Rees wrote:
On 2009-10-08, Ian Bicking <ianb@colorstudy.com> wrote:
So after creating, say, version 0.3.1, I always mark a package as 0.3.2dev. But this is annoying, you might never create a version 0.3.2 (e.g., 0.4 might be the next level). So, it would be better to use something like 0.3.1~dev. What is considered best practice for this? Ideally something that works with both Setuptools and the upcoming Distribute version spec.
a) Where's the annoyment exactly? It is easy to change and it's a release-time decision anyway.
- - It makes the package under development "look" like it is released, which is a Bad Thing for people who blindly want to depend on stuff. - - It creates lots of unnecessary commit message churn (go count how many messages on the zope-commits list are for "SVB" management). - - Furthermore, it (appears) to promise a release which may or may not ever be made - - It encourages people to forego thinking about what the correct release number should be (we've had a number of releases which should have been "feature" releses which got made using the "default next version" bugfix number).
b) In a previous discussion on a zope mailinglist (about using '0' for this purpose, which was pretty much shot down for the zope toolkit because of the problems attached to it), someone mentioned adding '+svn' to the previous version number. So from 0.3.1 to 0.3.1+svn. Apparently that sorts it behind 0.3.1. You could try something like that. The poster mentioned it as a debian standard.
The ZTK discussion was closed by fiat, not by achieving consensus. Neither Jim nor I agree with the proclamation, but will (grudgingly, in my case) abide by it within the context of the ZTK. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkrUvMAACgkQ+gerLs4ltQ5uiwCfeGfFO8VpkdKNszrDdKoEFLyT A20An0TkCQYjaxWdCRJmp/I68OvBTn2D =cRaR -----END PGP SIGNATURE-----
At 01:45 PM 10/13/2009 -0400, Tres Seaver wrote:
Reinout van Rees wrote:
On 2009-10-08, Ian Bicking <ianb@colorstudy.com> wrote:
So after creating, say, version 0.3.1, I always mark a package as 0.3.2dev. But this is annoying, you might never create a version 0.3.2 (e.g., 0.4 might be the next level). So, it would be better to use something like 0.3.1~dev. What is considered best practice for this? Ideally something that works with both Setuptools and the upcoming Distribute version spec.
"0.3.1-anything" will sort after "0.3.1" and before "0.3.2dev", so that's probably what you want. Typically, the "anything" would be a revision number or date tag (e.g r5143 or 20091005), but it could also be a manually-assigned sequential number. Technically, this is a "post-release" tag, and in the previous proposal for a restricted version format, you would designate it with 0.3.1.postNNNN.
participants (14)
-
Andrew Straw -
Ben Finney -
Benji York -
Chris Withers -
exarkun＠twistedmatrix.com -
Floris Bruynooghe -
Gerry Reno -
Ian Bicking -
Jim Fulton -
Lennart Regebro -
P.J. Eby -
Reinout van Rees -
Tres Seaver -
Zooko Wilcox-O'Hearn