Re: Preparing for 2.2

[Andreas Hochsteger]

Hi!

What's the intention behind creating different CVS repositories for 
different major releases?
Perhaps I'm missing something, but aren't branches and release tags the 
mechanism to manage this things in CVS?

I'm asking because changing the repository has several consequences. 
Here are some examples which come to my mind:
* CVS Documentation
* Development tools outside of the Cocoon CVS
* Migration/Integration to/with other version control systems (e.g. 
Subversion)
* Statistical and historical analysis is much more difficult
* Cocoon developers, which read the ML less often easily run into problems

I understand, that this is easier, if some heavy structural changes are 
done but is it necessary to do this for every major release?

Another question:
Why is everybody here talking from major release when just the second 
version number (the y in x.y.z) changes?
From many other opensource products I was used to the following 
termology (assuming x.y.z as version)
* x: Major version number
* y: Minor version number
* z: Patch level
What terminology are you using?

Please don't flame me, if I don't understand some of your wording or 
organizational conventions. I just want to make clear, that there's a 
difference in my understanding. Feel free to explain to me why you did 
not choose the standard way (at least as I thought it was).

Thanks for enlighten me ;-)

Bye,
        Andreas
Carsten Ziegeler wrote:

Finally, our beta (named rc) is out and I will create the announcements
tomorrow to give the mirrors a little bit of time.
So, by this, it means, we should only apply bug-fixes and docs to the
repository. 

Now, I think this applies only to the core, we can still change the blocks,
at least the blocks marked as alpha.
We now have to decide how to move on from here in order to start the
development for 2.2. 

We decided to create a new repository for each major version, so this
would require to create a cocoon-2.2 repository.
I think this is ok for the cocoon core, but not for the blocks as it
can be difficult to maintain two different sets.
So I suggest that we create the cocoon-2.2 repository and import
everything from 2.1 except all blocks. We change the build system
in 2.2 that it automatically takes during builing the blocks
from the 2.1 repo (I think it's a property anyway).
We could also link the docs and not import them in the same way,
keeping the new repository small in the beginning.
By this we have a simple way of starting development of the "real blocks"
and all the other nice changes we have in mind.
We have then time to think about how to handle blocks regarding cvs.
I could imagine to create own repositories for some "bigger" blocks etc.
But it's best to take small and simple steps for now.
What do you think?

Carsten