cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: Versioning of blocks
Date Sun, 08 Jan 2006 20:41:10 GMT
Carsten Ziegeler skrev:
> Daniel Fagerstrom schrieb:
>>Carsten Ziegeler skrev:
>>
>>>Thanks to the great efforts of Jorg and others we now have a m10n setup
>>>with the flattened layout. I hope this question is not stupid, but how
>>>do we do different versioning of blocks now?
>>
>>We discussed it in some detail in 
>>http://marc.theaimsgroup.com/?t=113102809100001&r=1&w=2
>>
>>Felix has recently moved to the same structure: 
>>http://mail-archives.apache.org/mod_mbox/incubator-felix-dev/200512.mbox/%3c43A988F8.20509@ungoverned.org%3e
>>
>>They have discussed the structure in considerable detail and has IMO 
>>excelent reasons for the chosen structure.
>>
> 
> Ok, I reread the thread, but from my understanding branches are not
> really dealt with.

Wrote about branches in a mail in the end of the thread: 
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=113120493104570&w=2

> 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.

 From the above post:

"So IMO there should not be a maintainamce branch like 2.2.x in the
future. Neither should there be a trunk that we don't release anything
from during several years. For blocks like the core and CForms that we
do a lot of work on we should do a relase from the trunk every 6-8 weeks.

If we for some reason need a bug fix release for an older release, say
that the latest cocoon core release from the trunk was 2.3.1 and that we
want to apply some bugfixes to cocoon core 2.2.3. Then we just copy the
released cocoon-core 2.2.3 to cocoon/branches do the bugfixing and when
we have finished them we release a new version by moving it back to
cocoon/releases and name it cocoon-core-2.2.4."

> 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.

A release is basically a POM wich states which version that is used for 
each block. So the 2.2.3 "complete release" would mean that some of the 
blocks have new 2.2 compatible maintainance releases, and the 2.2.3 POM 
is an update of the 2.2.2 POM with new versions of the updated blocks.

> It might be that the layout convers all these issues, but currently I
> don't see it, so if someone could please explain this here and please do
> not point to some other threads. Or even better, perhaps putting this
> into a howto/faq document would be even greater :)

The post I refered to is more or less a howto.

                --- o0o ---

Now, I think that the refered posts cover all cases except for doing 
extended parallel development of two "include all" Cocoon versions. And 
that is by design ;)

I propose that we follow these lines and see if it works. If it don't, 
we change it to something else.

/Daniel

Mime
View raw message