How to deal with major versions? (was Re: [Zope3-dev] Re: egg version numbers and zope releases)

Wed May 30 15:36:21 EDT 2007

On 30.05.2007, at 21:30, Jim Fulton wrote:

>
> On May 30, 2007, at 3:20 PM, Christian Theune wrote:
>
>> Hi,
>>
>> Am Mittwoch, den 30.05.2007, 15:12 -0400 schrieb Benji York:
>>> Jim Fulton wrote:
>>>> It's actually worse than that.  <2.0 would admit 2.0a1. :)  You'd
>>>> probably need something like < 1.99.
>>>
>>> I can deal with spelling dependencies on major version X as <= X. 
>>> 999.
>>>
>>>> Even if developers remembered, it would be icky to have to spell  
>>>> out
>>>> something like >=3.4 <=3.99 on everwhere.
>>>
>>> Not as icky (IMHO) as having distribution names with embedded major
>>> version numbers.  I'm interested in other people's opinions here.
>>
>> I don't like version numbers encoded in package names. I consider  
>> this
>> to be a work-around for packaging systems that aren't rich enough.
>>
>> (Gentoo for example gets this right.)
>
> Could you elaborate on this?

well :) i'm co-maintainer of the net-zope herd in gentoo:

read my attempt to improve the plone versioning: http:// 
article.gmane.org/gmane.comp.web.zope.plone.devel/3227/match=version 
+gentoo+batlogg

in summary:

Naming release tarballs (adapted from the gentoo conventions ;-))

file names consist of three logical sections:

The first section is the package name, which should only contain  
lowercase
letters, the digits 0-9, and any number of single hyphen ('-') or
underscore ('_') characters. Some examples are cmfplone,  
cmfquickinstaller,
formulator,...

The second section is the version of the package, which should  
normally be
same as the version of the contained product. The version is normally  
made
up of two or three numbers separated by periods, such as 1.2 or  
4.5.2, and
may have a single letter immediately following the last digit; e.g.,  
1.4b
or 2.6h. The package version is joined to the package name with a  
hyphen;
for example: foo-1.0, bar-2.4.6, etc.

Important: If you're thinking of using a trailing letter in your version
string, note that the trailing letter should not be used to signify  
alpha
or beta status for the package, since alphas and betas are  
prereleases and
letter revisions are newer versions. It's very important that version
numbers faithfully represent the version of the package so that  
depenency
checking is possible.

The third (optional) section contains a special suffix; either _alpha,
_beta, _pre (pre-release), _rc (release candidate), or _p (patch).  
Any of
these suffixes may be immediately followed my a number; e.g.,
linux-2.4.0_pre10; Assuming identical version parts, an _alpha  
package is
older than _beta, _beta older than _pre, _pre older than _rc, and _rc  
older
than _p. This section is meant to reflect upstream versions only.

Note: An _rc package is older than a package without an underscore  
prefix
(i.e. linux-2.4.0), and linux-2.4.0 is older than a package with a  
single
letter prefix, i.e. linux-2.4.0b. As you would expect, the linux-2.4.0b
package is considered older than linux-2.4.0c.

... and I suppose that we actually have a fourth section of the file  
name --
the .tar.gz extension itself.

>
>>>> Maybe there is some kind of dependency syntax that reads well that
>>>> means "I want this major version".  Can you think of a syntax  
>>>> that is
>>>> actually nicer than foo2?
>>>
>>> I can think of a syntax, but don't know if setuptools supports it.
>>> Perhaps I should look that up.  But I wont.
>>
>> I read the documentation on the version numbers multiple times and  
>> can't
>> remember anything that supports our use case.
>>
>> Maybe we should as pje whether there is something like what we  
>> imagine?
>
> I think I know what the answer will be.  After all, there is a  
> syntax for getting what we want.  The problem with it, IMO, and I  
> think in other people's opinion is that it is too cumbersome.
>
> IMO, having every dependency look like:
>
>    project_name >=X.y.z <X.999
>
> Is too cumbersome.  Maybe we should get over that. Maybe many other  
> people don't think it's too cumbersome.  Alternatively, maybe  
> someone can think of a prettier/more-concise syntax and sell it to  
> PJE.
>
> I'll note that this is especially cumbersome if, as I believe, for  
> 90% of packages, there isn't any good reason to make backward  
> compatible changes, at least after initial development.  So all  
> packages would end up getting a dependency-specification tax even  
> though only a few packages will need backward compatibility changes.
>
> Jim
>
> --
> Jim Fulton			mailto:jim at zope.com		Python Powered!
> CTO 				(540) 361-1714			http://www.python.org
> Zope Corporation	http://www.zope.com		http://www.zope.org
>
>
>
> _______________________________________________
> Zope3-dev mailing list
> Zope3-dev at zope.org
> Unsub: http://mail.zope.org/mailman/options/zope3-dev/batlogg.lists% 
> 40lovelysystems.com
>

--
"In the face of ambiguity, refuse the temptation to guess."
   -- The Zen of Python, by Tim Peters

Jodok Batlogg, Lovely Systems
Schmelzhütterstraße 26a, 6850 Dornbirn, Austria
phone: +43 5572 908060, fax: +43 5572 908060-77

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2454 bytes
Desc: not available
Url : http://mail.zope.org/pipermail/zope3-dev/attachments/20070530/ce24afb7/smime.bin