[Zope3-dev] [URGENT] Organising the satellite projects, eggs and version numbers before beta today

[Christian Theune]

Hi,

Am Donnerstag, den 03.05.2007, 09:27 -0400 schrieb Jim Fulton:
> On May 3, 2007, at 4:56 AM, Christian Theune wrote:
> 
> > Hey,
> >
> > I'm in front of the same wall that Fred was going up. ;)
> >
> > I talked to Zagy about the problems we're facing with the current egg
> > releases of projects that live in Zope3/src/zope/ and
> > Zope3/src/zope/app/ and wrote this up a bit:
> >
> > Problems
> > ========
> >
> > When working with eggs, we need to carefully use version numbers  
> > for the
> > releases and be able to do continuous releases.
> 
> By continuous releases, do you mean releases with version numbers  
> that look like: 1.1dev-r1234?  If so, I'm not convinced we'll need  
> this at steady state for most projects.  For most packages, regular  
> releases, possibly augmented by the occasional alpha or beta release  
> should be enough, IMO.

Well. We're currently tracking the upcoming 3.4 release for a software
project. By doing this we discover smaller missing features or bugs that
we fix as we go along targeting the stable 3.4 release for our software
when it is done.

Typically my workflow is like this:

- Find something that needs a change in a third party project (that is
  available as an egg and that I manage in zc.buildout)
- Check out the correct branch of the third party project.
- Apply the change, make sure tests run etc, check it in.
- Create a .dev-r1234 release that will now be the (minimal) requirement
  for our project as we know the fix is in there.

This helps that no other developers have to cope with the fact that the
change is *currently* only available as a dev release, which is fine
while we are developing our application. We'll later help getting a
stable release of that piece of software that we can refer to from our
project.

I find this workflow useful.

> > This is currently a bit
> > icky:
> >
> > - Coding in the tree doesn't force you to get the individual
> > dependencies right, especially when dependencies evolve over time and
> > require constraints based on the version number.
> >
> > - Releasing and tagging doesn't go together very well in this schema,
> > although continuous releases shouldn't require tags anyway. The normal
> > continuous releases from setuptools get somewhat awkward because we  
> > have
> > the indirection of the external.
> 
> The current schema of making projects with externals pointing into  
> the Zope tree was always meant to be a temporary measure.
> 
> 
> > I was trying to think about the constraints of handling the large tree
> > when moving the code of all projects into satellite projects. IIRC the
> > requirement is that all projects that we move out now will get a  
> > common
> > version number.
> 
> I don't think that is a requirement.  It is a likely consequence of  
> the fact that they will likely already have been released with a  
> common version number.  Because version numbers should be increasing,  
> they will tend to stay in sync for a while.

Thanks. It's good you say that. That was definitely misinterpreted by me
then. All the hassle suddenly goes away.

> As soon as code for a project moves from the Zope tree to the project  
> tree, then the project can use whatever version numbers it wants as  
> long as they are increasing.
> 
> So I think you should omit the last 4 steps above.
> 
> You also need to add externals in the Zope 3 tree that point to the  
> new locations.  This assumes that the 3.4 releases will be made from  
> the Zope 3 tree or that you want to support development with the Zope  
> 3 tree at least a while longer.

Yes, I was planning to do that. I thought it was among my notes up
there. To recapture: the release will be built from the tree, all
software (src/) will live in the satellite projects.


> No synchronized versions please.

Understood! :)

I feel like having consensus with respect to the posts of you, Benji,
Fred and myself. Zagy was agreeing as well. Is that right?

Christian

-- 
gocept gmbh & co. kg - forsterstraße 29 - 06112 halle/saale - germany
www.gocept.com - ct at gocept.com - phone +49 345 122 9889 7 -
fax +49 345 122 9889 1 - zope and plone consulting and development
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://mail.zope.org/pipermail/zope3-dev/attachments/20070503/a894a53f/attachment.bin