[Zope3-dev] Re: A thought on backward compatibility and minimum versions

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jim Fulton wrote:
> In thinking about how we might specify that we want to depend on  
> major versions but sometimes need to specify minimum versions, the  
> following occurred to me:
> 
> - Suppose that we always had access to the latest released version,
> 
> - Suppose that, within a major release, all releases were backward  
> compatible,
> 
> Then I assert that there is no *need* to specify a minimum release  
> within a major release.
> 
> Consider an example:
> 
> I depend on foo 2 (foo >=2 <2.999).  Now foo 2.5 introduces a new  
> feature and I use this feature. In reality, I now depend on version  
> 2.5 or higher (and <2.999).  I shouldn't need to specify this. After  
> all, I'll always get new releases.  Why wouldn't I?  Well, I might  
> also depend on bar and bar might depend on foo <=2.4. Why would bar  
> do this?  The only sane reason is that 2.5 introduced a backward- 
> incompatible change, but we don't allow that.  If we don't have to  
> worry about backward incompatible changes within a major release  
> cycle, then there is no reason to set an upper limit and therefore,  
> there is no *practical* need to specify a lower limit.
> 
> Combined with the fact that that great majority of packages don't  
> change very much after they have become stable, I think most package  
> dependencies could be expressed very simply if there was a simple  
> syntax to specify *just* the major version.  In the context of  
> setuptools, I think "*" could be used, as has been suggested, but  
> without leading =s.  So, to specify foo version 2, I think the  
> following syntax would be very reasonable:
> 
>    foo 2*
> 
> This wouldn't prevent someone from specifying a minimum version.  For  
> example, to combine this with a minimum requirement of 2.5:
> 
>    foo 2* >=2.5
> 
> If people like these ideas, I'd be willing to lobby for them on the  
> distutils sig, especially if I have help. :)
> 
> Note that the proposal would be that, a specification of the form if  
> a version number followed by a * would be equivalent to a range:
> 
>     "project_name V*" is equivalent project_name "V.*" is equivalent  
> to "project_name >=V <V.99999"
> 
> (Or maybe equivalent to "project_name >=V.dev <=V.99999".)
> 
> Also note that It's not clear that the * is needed.
> 
> "foo 2" isn't a valid specification.  We *could* extend the  
> requirements language to allow a project name followed by a version  
> number.  So:
> 
>     "prject_name V" is equivalent to "project_name >=V <V.99999".

I'd rather have the dot, e.g. "foo 2.* >= 2.5", just for clarity:

  - It makes the intent clearer (that you want any version in the
    "two dot" release line).

  - It disambiguates the case where the version number might have
    double digits (e.g, '0.1' vs. '0.10').

Another feature I'm not sure is already in setuptools:

  - I *don't* want dev releases to replace production ones
    implicitly:  no package should be able to install a non-released
    version without explicit callout.  If this isn't already the
    default behavior, then I'd like syntax for spelling it.


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGXuKo+gerLs4ltQ4RArrWAJwMowPxfb95Jl7oAUCZUQCRD7o8kQCcD9+G
kGpfoL51tpgWWWlgpOwXktY=
=5KVO
-----END PGP SIGNATURE-----