You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@s-und-n.de> on 2004/04/23 11:03:36 UTC
[Vote] Repository Usage and Versioning
Rethinking our version structure and moving to subversion seems to
indicate that we should rethink our repository usage.
I think we should use one repository per major version, so one
repository for all 2.x versions (except 2.0.x versions that we
leave the way it is).
Then one repository for testing new stuff, like the new block
system - this will be the sandbox or scratchpad repository.
And finally - as we already have - the site repository.
As recently reported we already have incompatible changes from 2.1.4
to 2.1.5 (which we accepted to have!) and as I pointed out lately
I want to remove some deprecated stuff to continue the development
of the current version. And we have some major changes, like the
Cocoon forms that justify a minor version changes anyway.
So, I think, we should:
- tag the current cvs in order to create a branch if required
- change the version to 2.2, so this will be our next release
- try to follow the versioning guide (which is a work-in-progress)
- move to subversion whenever we want
- if the need for a 2.1.5 release arises we create a branch,
revert the incompatible changes and use the branch
This allows us to continue the development of Cocoon in any direction
without worrying about versions and how this fits into the development
of blocks. Blocks (and perpaps other features) can be developed
independently in a sandbox/scratchpad and when they are mature enough
can be moved in the main trunk. This can then result in a new
major or a new minor version. We can decide this when the time comes.
Carsten
Carsten Ziegeler
Open Source Group, S&N AG
http://www.osoco.net/weblogs/rael/
Re: [Vote] Repository Usage and Versioning
Posted by Marc Portier <mp...@outerthought.org>.
+1 from me
-marc=
Joerg Heinicke wrote:
> On 23.04.2004 11:03, Carsten Ziegeler wrote:
>
>> Rethinking our version structure and moving to subversion seems to
>> indicate that we should rethink our repository usage.
>>
>> I think we should use one repository per major version, so one
>> repository for all 2.x versions (except 2.0.x versions that we
>> leave the way it is).
>
>
> +1
>
>> Then one repository for testing new stuff, like the new block
>> system - this will be the sandbox or scratchpad repository.
>
>
> +1
>
>> And finally - as we already have - the site repository.
>
>
> +1
>
>> As recently reported we already have incompatible changes from 2.1.4
>> to 2.1.5 (which we accepted to have!) and as I pointed out lately
>> I want to remove some deprecated stuff to continue the development
>> of the current version. And we have some major changes, like the
>> Cocoon forms that justify a minor version changes anyway.
>>
>> So, I think, we should:
>> - tag the current cvs in order to create a branch if required
>
>
> Isn't the 2.1.4 release tag enough?
>
>> - change the version to 2.2, so this will be our next release
>
>
> +1
>
>> - try to follow the versioning guide (which is a work-in-progress)
>
>
> +1
>
>> - move to subversion whenever we want
>
>
> +1
>
>> - if the need for a 2.1.5 release arises we create a branch,
>> revert the incompatible changes and use the branch
>
>
> Doing it from the 2.1.4 release tag we do not even need to revert
> incompatible changes.
>
> Joerg
>
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/mpo/
mpo@outerthought.org mpo@apache.org
RE: [Vote] Repository Usage and Versioning
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Joerg Heinicke wrote:
>
> Doing it from the 2.1.4 release tag we do not even need to
> revert incompatible changes.
>
D'oh, yepp, sometimes it's easier than one thinks. Of course,
you're right we should use that tag!
Thanks!
Carsten
Re: [Vote] Repository Usage and Versioning
Posted by Joerg Heinicke <jo...@gmx.de>.
On 23.04.2004 11:03, Carsten Ziegeler wrote:
> Rethinking our version structure and moving to subversion seems to
> indicate that we should rethink our repository usage.
>
> I think we should use one repository per major version, so one
> repository for all 2.x versions (except 2.0.x versions that we
> leave the way it is).
+1
> Then one repository for testing new stuff, like the new block
> system - this will be the sandbox or scratchpad repository.
+1
> And finally - as we already have - the site repository.
+1
> As recently reported we already have incompatible changes from 2.1.4
> to 2.1.5 (which we accepted to have!) and as I pointed out lately
> I want to remove some deprecated stuff to continue the development
> of the current version. And we have some major changes, like the
> Cocoon forms that justify a minor version changes anyway.
>
> So, I think, we should:
> - tag the current cvs in order to create a branch if required
Isn't the 2.1.4 release tag enough?
> - change the version to 2.2, so this will be our next release
+1
> - try to follow the versioning guide (which is a work-in-progress)
+1
> - move to subversion whenever we want
+1
> - if the need for a 2.1.5 release arises we create a branch,
> revert the incompatible changes and use the branch
Doing it from the 2.1.4 release tag we do not even need to revert
incompatible changes.
Joerg
Re: [Vote] Repository Usage and Versioning
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 23 Apr 2004, at 10:03, Carsten Ziegeler wrote:
>
> I think we should use one repository per major version, so one
> repository for all 2.x versions (except 2.0.x versions that we
> leave the way it is).
Can't we just have ONE repository for ALL? it's just makes life easier
when copying/moving files around and we can fragment that repository as
finegrained as we want...
For example:
/cocoon/ <- this is the repository
/2.0/
/trunk/ <- trunk of 2.0
/tags/ <- tags of 2.0
/2.1/
/trunk/ <- trunk of 2.1
/tags/ <- tags of 2.1
And so on and so forth...
Pier
Re: [Vote] Repository Usage and Versioning
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 23 avr. 04, à 11:56, Upayavira a écrit :
> ...I really think we should get away from this idea of multiple
> repositories. Subversion should, I believe, fix the problems that led
> us to our multiple repository situation, and therefore we should have
> just two repositories: code and site. (Of course we leave 2.0 where it
> is)....
I haven't played with subversion yet but this sounds right. Being able
to do diffs and merges between the different versions of Cocoon will be
much more useful than disjointed repositories.
-Bertrand
Re: [Vote] Repository Usage and Versioning
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Pier Fumagalli wrote:
> On 23 Apr 2004, at 11:44, Nicola Ken Barozzi wrote:
>
>>
>> with SVN we will have this dir structure:
>>
>> /cocoon
>> /trunk
>> /site
>> /src
>> ...
>> /branches
>> /cocoon2.1
>> /site
>> /src
>> ...
>>
>> Please read play with SVN a bit, as it has a different and better way
>> to handle these things
>
> I think that every version should have its own "trunk" and "tags" so
> that parallel development on more than one revision can happen easily...
It was just OTOMH, but your proposal seems better :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [Vote] Repository Usage and Versioning
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 23 Apr 2004, at 11:44, Nicola Ken Barozzi wrote:
>
> with SVN we will have this dir structure:
>
> /cocoon
> /trunk
> /site
> /src
> ...
> /branches
> /cocoon2.1
> /site
> /src
> ...
>
> Please read play with SVN a bit, as it has a different and better way
> to handle these things
I think that every version should have its own "trunk" and "tags" so
that parallel development on more than one revision can happen
easily...
Pier
RE: [Vote] Repository Usage and Versioning
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Nicola Ken Barozzi wrote:
>
> Upayavira wrote:
>
> > Carsten Ziegeler wrote:
> >
> >> Rethinking our version structure and moving to subversion seems to
> >> indicate that we should rethink our repository usage.
> >>
> >> I think we should use one repository per major version, so one
> >> repository for all 2.x versions (except 2.0.x versions
> that we leave
> >> the way it is).
> >>
> > I really think we should get away from this idea of multiple
> > repositories. Subversion should, I believe, fix the
> problems that led
> > us to our multiple repository situation, and therefore we
> should have
> > just two repositories: code and site. (Of course we leave
> 2.0 where it is).
> >
> > If we don't do this, we loose all sorts of benefits, e.g. merging
> > branches, lazy branching, etc, etc. And if there's no 'cost' in
> > Subversion for branching (like there is in CVS), then why not do it?
>
> The fact is that in subversion, a branch is just a dir! So
> this whole discussion about how many "repositories" to have
> is moot, as we can copy
> and move things round as many times as we want, all
> retaining history and with *cheap* copies (IOW the same file
> that is not modified is stored only once inside the repo and
> referenced in two places).
>
> So we now have
>
> cocoon-2.1 (repo)
> cocoon-2.2 (repo)
>
> with SVN we will have this dir structure:
>
> /cocoon
> /trunk
> /site
> /src
> ...
> /branches
> /cocoon2.1
> /site
> /src
> ...
>
> Please read play with SVN a bit, as it has a different and
> better way to handle these things.
>
With my proposal from above we would have the same with CVS, one
repository. I only mentioned our additional repositories (like
the site repository) and that it might make sense to have a clean
start for a new major version (Cocoon 3.0).
Actually, I don't care if we use subversion or cvs and as most of
us here are eagerly waiting to use svn, we should simply move to
subversion if we can agree on the general meaning of the above
proposals (or come to a different conclusion).
Carsten
Re: [Vote] Repository Usage and Versioning
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Upayavira wrote:
> Carsten Ziegeler wrote:
>
>> Rethinking our version structure and moving to subversion seems to
>> indicate that we should rethink our repository usage.
>>
>> I think we should use one repository per major version, so one
>> repository for all 2.x versions (except 2.0.x versions that we
>> leave the way it is).
>>
> I really think we should get away from this idea of multiple
> repositories. Subversion should, I believe, fix the problems that led us
> to our multiple repository situation, and therefore we should have just
> two repositories: code and site. (Of course we leave 2.0 where it is).
>
> If we don't do this, we loose all sorts of benefits, e.g. merging
> branches, lazy branching, etc, etc. And if there's no 'cost' in
> Subversion for branching (like there is in CVS), then why not do it?
The fact is that in subversion, a branch is just a dir! So this whole
discussion about how many "repositories" to have is moot, as we can copy
and move things round as many times as we want, all retaining history
and with *cheap* copies (IOW the same file that is not modified is
stored only once inside the repo and referenced in two places).
So we now have
cocoon-2.1 (repo)
cocoon-2.2 (repo)
with SVN we will have this dir structure:
/cocoon
/trunk
/site
/src
...
/branches
/cocoon2.1
/site
/src
...
Please read play with SVN a bit, as it has a different and better way to
handle these things.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [Vote] Repository Usage and Versioning
Posted by Upayavira <uv...@upaya.co.uk>.
Carsten Ziegeler wrote:
>Rethinking our version structure and moving to subversion seems to
>indicate that we should rethink our repository usage.
>
>I think we should use one repository per major version, so one
>repository for all 2.x versions (except 2.0.x versions that we
>leave the way it is).
>
>
I really think we should get away from this idea of multiple
repositories. Subversion should, I believe, fix the problems that led us
to our multiple repository situation, and therefore we should have just
two repositories: code and site. (Of course we leave 2.0 where it is).
If we don't do this, we loose all sorts of benefits, e.g. merging
branches, lazy branching, etc, etc. And if there's no 'cost' in
Subversion for branching (like there is in CVS), then why not do it?
>Then one repository for testing new stuff, like the new block
>system - this will be the sandbox or scratchpad repository.
>
>
Do this in a named branch or branches which can be merged into head when
the code is ready.
>And finally - as we already have - the site repository.
>
>
Yup.
>As recently reported we already have incompatible changes from 2.1.4
>to 2.1.5 (which we accepted to have!) and as I pointed out lately
>I want to remove some deprecated stuff to continue the development
>of the current version. And we have some major changes, like the
>Cocoon forms that justify a minor version changes anyway.
>
>So, I think, we should:
>- tag the current cvs in order to create a branch if required
>- change the version to 2.2, so this will be our next release
>- try to follow the versioning guide (which is a work-in-progress)
>- move to subversion whenever we want
>- if the need for a 2.1.5 release arises we create a branch,
> revert the incompatible changes and use the branch
>
>
Sounds okay, I guess.
>This allows us to continue the development of Cocoon in any direction
>without worrying about versions and how this fits into the development
>of blocks. Blocks (and perpaps other features) can be developed
>independently in a sandbox/scratchpad and when they are mature enough
>can be moved in the main trunk. This can then result in a new
>major or a new minor version. We can decide this when the time comes.
>
>
As I say, I think they can/should be developed in SVN branches that can
be merged back into head when sufficiently developed.
Otherwise, all sounds fine.
Regards, Upayavira