On Jul 2, 2014, at 12:45 PM, Andrew Phillips <aphill...@qrmedia.com> wrote:
>> Some projects never break client code. I think that’s one extreme that >> won’t serve us or our users well. To ease any pain associated with breaking >> code, we do need to make it very predictable. And making breaking changes >> at major release boundaries only achieves that goal. > > I think we're definitely agreed that we shouldn't make breaking changes > except in major releases. My comment - apologies if it wasn't stated clearly > - was that I'm hesitant to restrict ourselves to also *announcing* upcoming > breaking changes in major releases. > > I agree that we certainly should avoid deprecating something in 2.9 and > breaking it in 3.0, but deprecating it in 2.1 and breaking it in 3.0 (with > requisite warnings, questions on user@) etc. seems reasonable to me in > general. Basically I’m looking for a guaranteed *minimum* amount of time for users to be able to react to breaking changes. Considering the long release cycles in place at many organizations, I think 6 months is the absolute minimum. If we had a 6 month major release cadence, announcing upcoming breaking changes on major release (X.0 only) would be necessary. If we had a 9 month major release cadence, announcing upcoming breaking changes on major release or the two releases after (X.0, X.1, and X.2 only) would be possible. > Curious to hear what others feel about that? Me too. Perhaps it’s lazy consensus at work. :) >> I see what you mean but wouldn’t that make backporting very difficult if >> not impossible in some situations? > > Could you explain? I would imagine that if we wanted to remove a piece of > functionality on master (and, of course, we don't *have* to do this - I'm > just not sure we want to ban it), we would: > > 1) Push a commit that deprecates the functionality we want to remove and > presumably adds an alternative > 2) Backport that commit to the current release branch > 3) If desired, push a subsequent commit to master to remove the deprecated > functionality Hmmmm…maybe this would be okay. Any new code added after (3) that used the alternative would still be able to be backported. I can’t think of a counter-example... >> I understand now. What did you think of this alternative wording? >> >> "Beta methods and classes will be promoted to non-beta status or removed >> only in major releases (e.g. MAJOR.0)" > > That sounds fine to me. It doesn't give any indication of *how many* major > releases you might have to wait, though. I'm perfectly OK of not including > such an indication if we feel it doesn't make sense, by the way. I’m okay not including such an indication. I think it’s okay to take things out of Beta in minor releases if we feel they’re ready. It’s an addition and not a change so no danger of breaking anyone. Thanks for the good discussion! Everett
