Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <3F280FB3.6040101@student.tuwien.ac.at>
Date: Wed, 30 Jul 2003 20:34:27 +0200
From: Andreas Hochsteger <e9625392@student.tuwien.ac.at>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-AT;
 rv:1.4) Gecko/20030612
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Preparing for 2.2
References: <LKENJPKDAIKAPKHEOCMMGEPEEGAA.cziegeler@s-und-n.de>
In-Reply-To: <LKENJPKDAIKAPKHEOCMMGEPEEGAA.cziegeler@s-und-n.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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