In general, yes, we just have a public branch for a release which continues to be maintained, which is a good thing.
My concern is that, in this case, the one calling for the branch is not the Trinidad/MyFaces community, but a specific company. Ideally, the two match up and agree, in which case there's no problem. But the question is - when a company wants an extra branch that the community at large doesn't need, is that a problem? Say, if the community wants one more bug fixed, but the company says "we need a branch now", what happens? I don't see any harm to the project by having extra branches in subversion, but I don't want to assume it's OK without asking everyone here. Thanks, Adam On 8/14/06, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
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
