The problem with merging up to the branch is that you can end up adding a bunch of experimental stuff into the about to be released branch. Its much easier to merge the entire branch down to the trunk instead of merging bits and pieces up to the branch. Either way the urgent fixes need to be merged right away and it ultimately doesn't make too much difference which direction the merge occurs in as long as we have a consistent policy.
As for the slow release cycles - we are doing our best. If people have complaints they should step up and help. I think a consistent fix policy and a policy of not allowing anymore snapshots into the maven builds (unless they are myfaces snapshots) should help in the future. Sean On 3/9/06, Mike Kienenberger <[EMAIL PROTECTED]> wrote: > On 3/9/06, Sean Schofield <[EMAIL PROTECTED]> wrote: > > Realistically I think we're talking every 2 months. Especially if you > > factor in the time to do separate Tomahawk and Tobago releases every > > so often also. > > We either need to start releasing more frequently (at least once a > month so long as we have outstanding bugs) or we need to start > patching release branches (ie, Myfaces 1.1.1.1, 1.1.1.2, etc) when we > have major-or-greater bug fixes on trunk. > > I'm starting to see some complaints on other JSF-related mailing lists > by individuals who feel that they have to use a "blessed" release > (even though in my opinion there's very little difference between a > nightly and a "blessed" release at this point in time other than a > quick check to be sure things aren't obviously broken) and are > frustrated by our current release schedule (only three releases in the > last year). > > For example, MyFaces 1.1.1 isn't usable with Facelets due to the > duplicate id bugs. > > On 3/9/06, Sean Schofield <[EMAIL PROTECTED]> wrote: > > NOTE: Crucial fixes should go on the *branches* only. I will merge > > them down to the trunk later. The worst thing you can do is fix them > > on both. > > I really think we need to either shorten the time we take to make > releases, or we need to rethink our strategy here. My preference is > that "trunk" should be our authoritative version, and patches should > be applied here first. Releases should be considered static, and > once a release branch is made, it should either be frozen or a patch > should be merged *to the release branch* after being committed to > trunk, not the other way around. If there are too many critical > patches made for this to be feasible, then that's probably an > indication that the current release should be aborted and the process > restarted. > > The way things stand, every time we start a release process of any > kind, the entire usability of the nightlies or trunk is gone due to > these artificially-imposed "locks" on the trunk. And unfortunately, > we seem to be in a permanent holding pattern these days due to > everything that's going on. > > Maybe it's just my limited experience, but I'm unaware of any other > project that makes the trunk dependent on and subservient to changes > to the release branch! >
