Jorg Heymans wrote:
> Carsten Ziegeler wrote:
>
>
>>Hmm, yes, like I wrote in my latest answer to Daniels post, I'm not sure
>>if this is the right approach. I think, blocks will be totally
>>independent wrt to releases/versioning from the core in the future. And
>
>
> Yes the release cycle of blocks will be totally independent of the core
> release cycle. The actual versioning is independent as well.
>
> The fact that my suggestion copies ./trunk to ./branch does not mean
> that we tie the release or versioning of blocks in ./branch to that
> core. It just means that we explicitly state that those blocks are only
> guaranteed to be working with that particular core. The branch would
> effectively be in maintenance mode, meaning you'ld only backport
> *critical* bugfixes.
>
Hmm, ok, sorry it must be the early time of the year that I don't get it :(
I'll try to repeat what I understood so far with an example. Assume we
have the core and three blocks, A, B and C. For simplification we start
all blocks with 1.0 while the core gets version 2.2:
+ trunk
+ core (2.2)
+ block A (1.0)
+ block B (1.0)
+ block C (1.0)
Now, we release everything and continue development (tagging is imho not
an issue, so I'll leave that out):
+ trunk
+ core (2.3)
+ block A (1.1)
+ block B (1.1)
+ block C (1.1)
So far everything is fine - now, we need a bug fix for 2.2, so we create
a branch (from the first release?). We name the branch 2.2.x:
+ branches
+ 2.2.x
+ core (2.2.x)
+ block A (1.0)
+ block B (1.0)
+ block C (1.0)
Now at this time, we only need a branch for the core as we only need a
bug fix for core, but not for the blocks. So branching the whole trunk
is not the right way. So I guess that you suggest to just branch the
core in this case?
+ branches
+ 2.2.x
+ core (2.2.1)
So, this would mean that all blocks in trunk are always related to the
core version. If you want to do a maintenance release for a block, you
create a branch under the core-version the maintenance release is
targetted at?
+ branches
+ 2.2.x
+ core (2.2.1)
+ block B (1.0.1)
Is it this what you mean or did I get it totally wrong :)
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
