cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject Re: Versioning of blocks
Date Sun, 08 Jan 2006 21:46:34 GMT
Daniel Fagerstrom wrote

> "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."
Hmm, ok, this might work - I have not thought about all implications yet
- but, I think this means that blocks are not versioned independently.
- we release 2.2 core and all blocks with version 2.2 (assuming that we
start each block with version 2.2 for simplifying this example).
- we continue development of the core from 2.2 towards 2.3 and finish
2.3 for the core. Now we can release 2.3 core.
- we have a block A that is at this time in development; it's not
finished for 2.3 yet.
- Now, checking out "trunk" and doing a complete 2.3 release would not
work, as there are blocks, like block A, which should not be released
with 2.3. So our convenience "full cocoon" release for 2.3 should
contain version 2.2 of block A.
Does this make sense?

At a later time, there will be a release 2.3 of block A using new
features from 2.3 core.
A separation of the blocks from the core allows us to do new releases of
the core without taking the state of all blocks into account.

Now, I'm not sure, but I think that having indepent blocks (from a
versioning perspective) should be reflected by the repository structure.

Carsten Ziegeler - Open Source Group, S&N AG

View raw message