cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <Ralph.Go...@digitalinsight.com>
Subject RE: [Vote] Repository Usage and Versioning
Date Fri, 23 Apr 2004 14:15:17 GMT
I'm still not clear on why multiple repositories are used now.

In any case, I've submitted some patches that I'd really like to see in
2.1.5 as I don't know if I'm ready for 2.2. I have no idea how the change
Carsten made to Request.getRequestURI is going to impact me as I do call
that method, and I really don't want to have to deal with that now.  I know
that other patches have been made to 2.1.4 that would also be good to have.
So I guess I would recommend the change to getRequestURI be backed out, a
2.1 branch be made (from which 2.1.5 would be built) and the change then be
reapplied to head for 2.2.  Unless, of course, I really don't understand how
Cocoon is being maintained.

Ralph

-----Original Message-----
From: Upayavira [mailto:uv@upaya.co.uk] 
Sent: Friday, April 23, 2004 2:57 AM
To: dev@cocoon.apache.org
Subject: Re: [Vote] Repository Usage and Versioning

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


Mime
View raw message