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
