[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xml-cocoon-dev
Subject:    Re: Preparing for 2.2
From:       "Christoph Gaffga" <cgaffga () triplemind ! com>
Date:       2003-07-30 18:47:09
[Download RAW message or body]

> * x: Major version number
> * y: Minor version number
> * z: Patch level

it's not only that easy, I would say that java 1.2 and 1.4 are also
majors! - just an example.

Christoph

----- Original Message -----
From: "Andreas Hochsteger" <e9625392@student.tuwien.ac.at>
To: <dev@cocoon.apache.org>
Sent: Wednesday, July 30, 2003 8:34 PM
Subject: Re: Preparing for 2.2


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

[prev in list] [next in list] [prev in thread] [next in thread]