[Zope-dev] setting missing minimum version in setup.py

[Roger Ineichen]

Hi Wichert, Steering Group?
  
> Betreff: Re: [Zope-dev] setting missing minimum version in setup.py
> 
> Previously Martijn Faassen wrote:
> > Wichert Akkerman wrote:
> > [snip]
> > > I see no useful different between x.y and x.y.z here. All 
> I want is 
> > > if someone installs one of our packages that package will 
> work as expected.
> > > If a package will only work with a certain revisions of a 
> dependent 
> > > package it has to state say.
> > 
> > I do see a useful difference between the two.
> > 
> > x.y is a feature release that might have changed the API or 
> behavior. 
> > If you rely on this in a version of your package, you will have to 
> > indicate that this is so.
> > 
> > x.y.z is a bugfix release. If we do it right, there will be 
> no change 
> > in the API and only small changes in misbehavior. Therefore 
> it seems 
> > far less likely to me that a package ends *needing* to depend on a 
> > minimum version. In addition, porting back bugfix releases 
> is far harder.
> 
> If version x.y of package A adds a new feature which requires 
> a feature in package B, but was broken in B until version 
> d.e.f of that package, I would expect version x.y of package 
> A to have a dependency on version d.e.f of package B. Do you 
> agree with that?

What do you do if version x.y works with d.e.d but not with
d.e.e (because it's borken) and fixed in d.e.f.

This means you could use d.e.d or d.e.f. but not d.e.e

What's your solution then?
Fix the version to d.e.d or d.e.f or skip fixing versions?

This is a use case where fixing versions in packages doesn't
work and the KGS only can help. You can have different KGS
version indexes. One with d.e.d and one with d.e.f.

This is the benefit of the KGS. You can define whatever you like
an nobody is able to block packages which you need to use.

Note; Not that fixing versions in a package is a bad thing
in general. But such fixed versions will mess up the KGS
that's the bad part. And since the KGS solves any kind of
version conflict problems, there is no way to do it in a
package anymore.

I think you are suggesting that we should be able to use
all package without a KGS. If so,you are right, then we need
fixed versions. But if we decide to use KGS as our primary
pattern, then we do not need to mess up with versions in packages.

Steering group?

Do we support a release management at package level or
do we only guarantee a working release/version management
based on KGS?

Regards
Roger Ineichen

> Wichert.
> 
> -- 
> Wichert Akkerman <wichert at wiggy.net>    It is simple to make things.
> http://www.wiggy.net/                   It is hard to make 
> things simple.
> _______________________________________________
> Zope-Dev maillist  -  Zope-Dev at zope.org
> http://mail.zope.org/mailman/listinfo/zope-dev
> **  No cross posts or HTML encoding!  ** (Related lists -  
> http://mail.zope.org/mailman/listinfo/zope-announce
>  http://mail.zope.org/mailman/listinfo/zope )
>