geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <>
Subject Re: Module restructure
Date Fri, 27 May 2005 18:25:52 GMT
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  
> 	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 

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.


View raw message