cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jorg Heymans>
Subject Re: Versioning of blocks
Date Sun, 08 Jan 2006 20:43:45 GMT

Carsten Ziegeler wrote:

> Ok, I reread the thread, but from my understanding branches are not 
> really dealt with. Now, as soon as we separate things (which in fact
> we have done now), branches will most like be unavoidable. For
> example, we release 2.2 core, then every block can depend on core
> version 2.2. So far no problem. Now, the core moves on to let's say
> 2.3 introducing new things, removing deprecated stuff whatever. Now
> it might make sense at that time to decide to keep two versions of a
> block. One, for maintenance, still depending on core v.2.2 - and the
> trunk of this block, depending on the latest and greatest core. I
> fail to see how this directly layout will solve this issues. I think 
> this layout assumes that always everything is using the latest
> versions.
> And what about doing maintenance release for 2.2 once 2.3 is in 
> development? We still want to ship releases, let's say 2.2.3
> containing all blocks (for convenience) which fit to 2.2 and of
> course not to 2.3. 

Once 2.2 goes into maintenance mode we could copy the whole of trunk to
/branches and release further updates from there. All blocks will still
be depending on 2.2 core.

Now for further updates to individual blocks that depend on 2.2 core
things are a bit trickier. One solution would be to only increment
within the current version, ie when a block is at version 1.6 when it's
copied to branch then only 1.6.1, 1.6.2 etc could be released from that
branch. Users of the block in trunk would get version 1.7 and so on.


View raw message