Le 27/05/11 10:03, Hanno Schlichting a écrit :
> On Thu, May 26, 2011 at 10:39 PM, Godefroid Chapelle
> <got...@bubblenet.be> wrote:
>> Le 26/05/11 17:15, Hanno Schlichting a écrit :
>>>> Smaller 1.4.x numbers could be kept for bug fix releases for CMF 2.1 and
>>>> Plone 3.
>>> That's a really weird way of doing it. And I'm a -1 on that.
>> I agree it is a bit weird, I am just trying to be creative to comply with
>> your request of preserving Plone 3 tests.
>> Outside being weird, can you explain issues you have ?
> You want to backport a feature that is known to break things into a
> stable release series.
It does not break things, this is too wide.
GS test suite was not touched outside places where tests did check
It would be much more fair to state that it is known to break tests setup.
> To me that's just wrong and defeats the very purpose of having stable
What I am actually trying to understand is which versions to give to
public releases after forking an existing branch.
The numbering scheme of those versions should fill the following goals :
- systems that depend on releases of the original branch should not be
- new releases of the original branch should be "pullable" without the
need to touch the existing systems.
- releases of the newest branch should have their own numbering so that
other packages can state unambiguous dependency on those new releases.
This is what dev releases are for (as you suggested).
My proposal is then the following : I would publish a
Products.GenericSetup 1.4.6dev001 release from my backported branch to PyPi.
And have p.a.testing 3.0.x depend explicitely on this GS 1.4.6dev001
release until there is a need for a new release of GS from this
Godefroid Chapelle (aka __gotcha) http://bubblenet.be
Zope-CMF maillist - Zope-CMF@zope.org
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests