Reinout van Rees wrote:
On 2009-10-08, Ian Bicking <[email protected]> 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
_______________________________________________
Distutils-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/distutils-sig
