geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <djen...@gluecode.com>
Subject Re: Module restructure
Date Fri, 27 May 2005 18:35:26 GMT
I'm worried that it would be a giant hassle to try to assemble a 
geronimo that is 90% stable and 10% unstable.

I also don't see the advantage of this plan over simply creating a 
branch whenever someone wants to do some disruptive experimentation, 
and merging the results back in when appropriate.  This worked fine for 
me for the work I did rewriting the jetty deployer. If I understand the 
svn docs this is more in line with "standard svn practice".

thanks
david jencks

On May 27, 2005, at 11:25 AM, Jeremy Boynes wrote:

> Aaron Mulder wrote:
>> On Fri, 27 May 2005, Geir Magnusson Jr. wrote:
>>> so we have /trunk and /branches/stable and /branches/unstable, the  
>>> former for release work, and the latter for really nutty stuff that  
>>> people want to work on, and head is where mainline development  
>>> continues?
>> 	Who's responsible for merging changes between branches so that 
>> unstable gets all the changes that go into stable and trunk?  That 
>> seems likely to be painful.
>
> We are. Stable is, well, stable, so there will be relatively few 
> changes made directly there (mainly bugfixes). The biggest chore will 
> be merging new features from (unstable,trunk) into stable as part of a 
> new release.  For a major release, we may just say the unstable tree 
> is now stable and  copy it over en-masse; for an incremental release 
> we may need to merge.
>
>
>> 	Also, is the expectation that a given module only goes in one
>> place (so transactions, if high-quality, have source only in stable or
>> whatever), or is the same code in all 3 and you're just expected to 
>> know
>> where to work on it?  If the latter, that sounds unwieldy too.  If the
>> former, then we should just have 2 or 3 separate dirs with their own
>> trunk, branches, and tags, right?
>
> Taking transaction as an example, let's say we consider it stable now. 
> We would have that as a module in the stable tree and the build would 
> output a specific version (say transaction-1.0.1). We would not need a 
> copy in the unstable tree, the unstable assembly could just use that 
> artifact.
>
> Now, David decides to implement some new feature, he copies the stable 
> branch into the unstable tree and starts implementing. At some point 
> he wants to integrate that with the unstable assembly so updates it to 
> use a SNAPSHOT version of his new module. When he's done and we all 
> agree that this should be part of the stable build, we merge the 
> changes back into the stable tree and re-release (say as 
> transaction-1.2.0).  The merge should not be too painful because there 
> would not have been a lot of changes in the stable tree.
>
> If he's done, we can switch the unstable assembly back to using the 
> new release build and delete the transaction module from the unstable 
> tree; if he wants to keep working on it then we just leave it there.
>
> The idea is to create a balance between users who want stable versions 
> that they can use and the desire to innovate.
>
> --
> Jeremy
>


Mime
View raw message