On 3/4/2016 7:35 AM, Robert Muir wrote: > On Fri, Mar 4, 2016 at 6:00 AM, Vanlerberghe, Luc > <luc.vanlerber...@bvdinfo.com> wrote: >> Basically, they apply changes at the lowest release for which the change is >> applicable and then merge the change upwards to the other releases and >> eventually to trunk. > This just creates a worse problem. Instead of "feature/bugfix didn't > make it into that release", you can have "feature/bugfix disappeared > entirely!".
I agree with Robert. Our usual method starts with master and works down. If the backporting doesn't happen, the change is not completely lost -- it will eventually make it into a release because at some point master will be branched into a new stable branch. With the bottom-up approach, if forward-porting the original commit doesn't happen, then the change will be gone from new releases the next time a higher branch is created. I understand the motivation to do it that way. Some things (deprecation removal in particular) are easier, but the top-down approach handles mis-steps better. We can always break from the usual pattern for situations where it makes sense (such as a change that includes deprecations), but I think changing the normal approach is the wrong thing to do. Thanks, Shawn --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
