Hey Sean, I know you're getting on a plane, but think about this while you're on there :)
If a patch is critical enough that it has to be put into a release branch, then someone needs to make the time to insure it's merged correctly -- and this hopefully is the exception rather than the rule. Either that, or a new branch is needed. Branches should be static once created so that development can continue in full force on the trunk. On 3/9/06, Sean Schofield <[EMAIL PROTECTED]> wrote: > 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! > > >
