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

[Jim Fulton]

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?

>>> 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