Re: [Numpy-discussion] Please comment on SVN versioning convention
On 7/25/06, Andrew Straw <[EMAIL PROTECTED]> wrote: > 1.0.2881 - This would sort after 1.0 (and 1.0b and 1.0c) and before 1.1 > for most tools out there. I like that best. Save the 1.1 prefix until it's actually released as such. The numbering scheme needs to deal with what to call the patch tip of the stable release branch, too. I.e. the maintenance release after 1.0 with only critical patches for anyone who demands strict 1.0 compatibility. The third number would be good for that. Right now I see 1.1.2881 as my version. I think this should probably have an extra .0 in it: 1.1.0.2881. That third number would be a maintenance release number. I also like the Linux even-odd system. Then 1.0.0.1234 can mean "SVN version on the 1.0 branch, leading up to maintenance release 1.0.1", and 1.1.0.1234 can mean "SVN version on the trunk, leading up to 1.2 release." --bb - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Please comment on SVN versioning convention
On Mon, Jul 24, 2006 at 04:03:13PM -0700, Andrew Straw wrote: > Sasha wrote: > > >On 7/24/06, Andrew Straw <[EMAIL PROTECTED]> wrote: > > > >>BTW, Fernando, all this is so that we can still have the svn revision > >>number in __version__, but so that it doesn't screw up sorting. > > > >Sorting __version__ is screwed up regardless of svn revision number: > > > '1.9' < '1.10' > > > >False > > > Not if you parse __version__ with something that understands version > numbers. ...and we've already got something for that: distutils.version.LooseVersion (or StrictVersion). -- |>|\/|< /--\ |David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/ |[EMAIL PROTECTED] - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Please comment on SVN versioning convention
On 7/24/06, Andrew Straw <[EMAIL PROTECTED]> wrote:
> Yes, I only brought up version numbers as strings because you did. I'm
> not proposing we solve that problem. I see setuptools, in particular, as
> the biggest thing to support, because it lets you have multiple versions
> installed simultaneously. And I don't know how to force its hand, or
> even if it's possible.
I am not familiar with setuptools and I expect that many others who
care about __version__ conventions are not either. Please explain
exactly how setuptools depend on what is stored in __version__ and
why using 'final' in place of svn revision number in file names will
not solve your problems.
I would be against any change that will affect map(int,
__version__.split('.')[:3]).
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Please comment on SVN versioning convention
Sasha wrote: >On 7/24/06, Andrew Straw <[EMAIL PROTECTED]> wrote: > > > >>BTW, Fernando, all this is so that we can still have the svn revision >>number in __version__, but so that it doesn't screw up sorting. >> >> > >Sorting __version__ is screwed up regardless of svn revision number: > > > '1.9' < '1.10' >False > Not if you parse __version__ with something that understands version numbers. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Please comment on SVN versioning convention
Sasha wrote: >On 7/24/06, Andrew Straw <[EMAIL PROTECTED]> wrote: >[snip] > > >>The concern is that there are a bazillion ways of sorting version >>numbers but the version numbers from numpy's current svn tree don't sort >>with (m)any of them. Sorting strings in Python is one way, using >>setuptools or debian's dpkg are other ways. >> >> > >Sorting numbers as strings is a problem no matter what tools you use. >'1000' is sorted before '999' in every tool I know of. The only proper >way to solve this problem is to make svn revision available as an >integer and sort them as integers. This integer may go in version_info >tuple or in a separate variable. The same information may be encoded >into a sortable string using appropriate padding, but I don't see much >need for that. > Yes, I only brought up version numbers as strings because you did. I'm not proposing we solve that problem. I see setuptools, in particular, as the biggest thing to support, because it lets you have multiple versions installed simultaneously. And I don't know how to force its hand, or even if it's possible. >Do you expect creating debian's dpkg from a >non-release version? > > Yes. I do personally (see http://debs.astraw.com/dapper/ for example) and I'm sure others do, as well. You can see from that archive that I've been dealing with this issue by adding appropriate suffixes or prefixes. (Forcing its hand.) - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Please comment on SVN versioning convention
On 7/24/06, Andrew Straw <[EMAIL PROTECTED]> wrote: > BTW, Fernando, all this is so that we can still have the svn revision > number in __version__, but so that it doesn't screw up sorting. Sorting __version__ is screwed up regardless of svn revision number: >>> '1.9' < '1.10' False - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Please comment on SVN versioning convention
On 7/24/06, Andrew Straw <[EMAIL PROTECTED]> wrote: [snip] > The concern is that there are a bazillion ways of sorting version > numbers but the version numbers from numpy's current svn tree don't sort > with (m)any of them. Sorting strings in Python is one way, using > setuptools or debian's dpkg are other ways. Sorting numbers as strings is a problem no matter what tools you use. '1000' is sorted before '999' in every tool I know of. The only proper way to solve this problem is to make svn revision available as an integer and sort them as integers. This integer may go in version_info tuple or in a separate variable. The same information may be encoded into a sortable string using appropriate padding, but I don't see much need for that. Do you expect creating debian's dpkg from a non-release version? - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Please comment on SVN versioning convention
Sasha wrote: >On 7/24/06, Travis Oliphant <[EMAIL PROTECTED]> wrote: > > >>Andrew Straw has emphasized that the current strategy of appending the >>SVN version number to development versions of the SVN tree makes it hard >>to do version sorting. >> >> > >I am not sure what the problem is, but if the concern is that > > > '0.9.9.2803' > '0.9.9' >True > >I suggest fixing that by appending '.final' to the release version string: > > The concern is that there are a bazillion ways of sorting version numbers but the version numbers from numpy's current svn tree don't sort with (m)any of them. Sorting strings in Python is one way, using setuptools or debian's dpkg are other ways. Remember, all this is only a concern for those working from SVN versions -- the releases are stripped of these numbers, anyway. I don't really care what we use, it's just that if we want to make life easy for people working from SVN, these automated tools should have a way of knowing that what we currently call numpy 1.1.2881 precedes numpy 1.1 (these are current examples from the SVN tree). Here are some proposals for this version: 1.0.2881 - This would sort after 1.0 (and 1.0b and 1.0c) and before 1.1 for most tools out there. 1.0.post2881 - This would sort after 1.0 (and 1.0b and 1.0c) and before 1.1 for most tools out there, but is perhaps more clear. 1.1.dev-r2881 - this wouldn't solve the problem for Debian, but it would for setuptools, which has special treatment for ".dev-r" (see http://peak.telecommunity.com/DevCenter/setuptools). This has the advantage of being only a minimal change from the current scheme. 1.0+1.1.2881 - I also think this would sort OK with most tools, and is also a fairly minimal change. My only concern is the '+' might cause some filesystems or tools to freak out. BTW, Fernando, all this is so that we can still have the svn revision number in __version__, but so that it doesn't screw up sorting. Cheers! Andrew - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Please comment on SVN versioning convention
On 7/24/06, Travis Oliphant <[EMAIL PROTECTED]> wrote: > Andrew Straw has emphasized that the current strategy of appending the > SVN version number to development versions of the SVN tree makes it hard > to do version sorting. I am not sure what the problem is, but if the concern is that >>> '0.9.9.2803' > '0.9.9' True I suggest fixing that by appending '.final' to the release version string: >>> '0.9.9.2803' > '0.9.9.final' False If we are going to make any changes in this area, I would suggest following python sys and define three variables: numpy.version (human readable string including compiler info), numpy.version_info (sortable tuple) and numpy.hexversion (sortable integer that can be used by C preprocessor). I am not sure if python sys includes svn revision number in sys.version (I don't have svn version of python around), but it does include it in beta sys.version: >>> print sys.version 2.5b2 (r25b2:50512, Jul 18 2006, 15:22:50) [GCC 3.4.4 20050721 (Red Hat 3.4.4-2)] - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Please comment on SVN versioning convention
On Mon, 24 Jul 2006 15:06:57 -0600 Travis Oliphant <[EMAIL PROTECTED]> wrote: > Andrew Straw has emphasized that the current strategy of appending the > SVN version number to development versions of the SVN tree makes it hard > to do version sorting. > > His proposal is to not change the version number until the first beta > comes out. > > In other words, the trunk should not be 1.1 but 1.0dev? > > Are there any opposing opinions to this change. I personally think that > is a confusing numbering scheme because 1.0dev seems to imply it's the > development for version 1.0 instead of 1.1. But, if several others > think it's a good idea to support easy-sorting of version numbers, then > I will conceed. > > Perhaps we can have a version 'number' as 1.0plus? What if we use even numbers for stable releases, odd for development releases, like for Linux kernels? e.g., make 1.1 the dev branch (current trunk), and make 1.2 the next stable release after 1.0. Or, make the trunk 1.0.99. The .99 usually makes it pretty clear that it's the development branch. -- |>|\/|< /--\ |David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/ |[EMAIL PROTECTED] - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Please comment on SVN versioning convention
On 7/24/06, Travis Oliphant <[EMAIL PROTECTED]> wrote: > Andrew Straw has emphasized that the current strategy of appending the > SVN version number to development versions of the SVN tree makes it hard > to do version sorting. > > His proposal is to not change the version number until the first beta > comes out. I have to say that being able to quickly see the actual SVN revision number in the version helps a LOT in tracking down problems. Just look at how many posts on the list start with the canonical In [4]: import numpy,scipy In [5]: numpy.__version__ Out[5]: '0.9.9.2803' In [6]: scipy.__version__ Out[6]: '0.5.0.2079' printouts before discussing the problem. I don't really feel strongly about the issue, but if you change this, then please add a __revision__ attribute as well, so that this information can be quickly asked for in pure python (we don't want to bother newbies with obscure SVN lingo, esp. if they got their install from someone else). Cheers, f - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
