2009/6/11 Eric Smith <e...@trueblade.com>: > I think this is an excellent point, and I think that both ways of doing it > need to be supported. The "counting up" method is especially useful if > you're moving toward 2 different versions, simultaneously. Think about > Python itself moving to 3.0. What should development versions of Python 3.0 > have been called, when both 2.6 and 3.0 were being developed? If only > "counting away" were supported, would all 3.0 build have been called > "alpha"? Certainly calling 2.6 and 3.0 "2.5 plus something" would have been > wrong, and a nightmare.
They weren't called anything (OK, internally all such releases have version number 2.6a0 and 3.0a0 respectively, but individual Subversion commits had no distinct version). And that's precisely right, as they are internal commits, and were not released. Why is there a need for every internal commit to have a distinct "version number"? I'm not saying there's no need to be able to identify the code base, but why must everything be lumped into the version? In my experience (and in the practice used by Python core) version numbers are for released versions. Snapshots, nightly builds, personal developer builds, etc, don't have version numbers. > True. When I'm "sneaking up" on an alpha release, I need to have version > comparisons work in my test environment, and I'd prefer to use "-dev". These > releases would never be published to PyPI or anywhere else, other than my > internal servers. I'm sorry, but why? How does your test environment work so that you are testing 2 versions at once, and need to compare "version numbers" programmatically? And why isn't something *additional* to the version number, like the core's sys.subversion, suitable? Please note, in case I seem excessively aggressive - my assumption is that the standard defined by the PEP doesn't have to be used by everyone, in all cases. You presumably have code that works at the moment, and you are perfectly entitled to continue using it. If you switch to the APIs proposed in the PEP, then presumably you see some benefits in following the standard. There's clearly a cost in doing so - one part of the cost is changing your code, and I don't think it's unreasonable for another part of that cost to be changing your version numbering scheme (at least for your released versions). Whether that cost is too high is a decision you have to make yourself. Designing the PEP is a compromise between all the various aspects involved. Paul. _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
