I think basicly that what you want is something like:
a branch for a release or a rc, which is also maintained.
I think that's fine with Apache, why not?
In MyFaces we do a branch for *each* release too, but we are
not maintaining the branches *after* the release (which is bad).
So the work will continue on trunk and if we figure out, that there is
a bug that stopps also the *released* / *branched* version of T.,
why not apply the *patch* against the branch too.
I prefer that too.
-Matthias
For some of our internal, non-open source work here at Oracle,
we're heavily depending on Trinidad (yay!). The catch is that,
at certain points, we need a stable branch to build off of and
apply only limited bug fixes so that internal work never gets
destabilized.
What I'd like to do is create branches in the Subversion repository
for Trinidad code, with the following commitments:
- No proprietary, non-Apache code will *ever* be checked in to
such branches.
- No work will happen on these branches that has not *first*
been checked into trunk, with the possible exception of deeply
hacky bug patches that wouldn't be wanted on a trunk.
In other words, this will still be public work, and never even
anything that could be construed as a fork in any way.
Does this seem reasonable? Is it legit by Apache rules?
All the alternatives I can think of are even less legit - e.g., we
could make an internal copy of the source code, but that just
reduces our exposure to the internal work and makes it less
straightforward for us to hew to the true code on the trunk.
-- Adam
--
Matthias Wessendorf
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
