On Wed, Nov 5, 2014 at 10:49 PM, Ferenc Kovacs <tyr...@gmail.com> wrote:
> 2014.11.06. 2:46 ezt írta ("Andrea Faulds" <a...@ajf.me>): > > > > > > > On 5 Nov 2014, at 20:34, Ferenc Kovacs <tyr...@gmail.com> wrote: > > > > > > Regardless of those, I think it would be worse from the users POV than > our > > > current policy where we target no BC breaks in minor/micro versions. > > > The only exception should be security concerns (see the unserialize > changes > > > in 5.6 for such an example), which shows that usually BC breaks are > more > > > about the tradeoff, having a BC for a cornercase which probably nobody > will > > > notice but it will simplify the langspec/parser is a different kind of > BC > > > that switching the needle/haystack argument order or removing the > dollar > > > sign would cause. > > > Trying to compare or quantify those are hard, and they should be > decided on > > > their own merrit not how much open slot do we have. > > > > > > Just my 2 cents ofc. > > > > Hmm. Wouldn’t allowing minor BC breaks in minor versions be better than > having BC breaks only in majors? Is it not easier to make one or two small > code changes each year, than to do a massive migration every 5 years? > > With major versions you have years to migrate(while we don't cover this in > our release process rfc, but we tend to keep the previous major version > alive for years) but I do agree that more frequent but smaller BC breaks > are better, but I would use that as an argument for having smaller but more > frequent majors. Like a new major version every 3 years where we provide > support 2years standard and 1 year security support, so we always have 2 > major branches active, but never have more than two minor versions for a > major. > But this probably needs a bit more thought. > It's more than just a matter of time and convenience, though. It also has to do with expectations. There is a predominant expectation that upgrading minor increments on the same major release branch is essentially safe; that you won't have to worry about BC breaks-- minor or otherwise-- causing your code to start failing. Furthermore, as someone else already pointed out, "major" and "minor" can be very subjective terms and would likely lead to increased confusion. Many maintainers would probably opt not to just stay on their current version rather than risk a BC break that someone here regarded as "minor" causing their code to blow-up. This is especially problematic given that essential security updates and bug fixes are frequently included in minor version releases. It could be argued that staying current with the latest minor increment on whatever major branch you're on is more important than being on the latest major increment for that very reason. I fear that this proposal would undermine that and erode the trust people currently have in our minor releases to be BC-friendly, drastically curtailing the proliferation of critical bug fixes and security updates. Historically, we haven't had much trouble on that side of the coin and I'd prefer to keep it that way. On the flip side, of course, there is also an expectation that major increments will have BC breaks and will likely require updates to your code; which, in turn, leads to the expectation that adoption of new major version releases will be gradual. I've often argued here that we tend to allow known flaws to persist in major version increments due to an inappropriate level of concern for BC in major release increments and I still believe that. That said, this proposal would represent the opposite extreme, making our minor releases too unreliable in terms of BC for many people's comfort. Also, the limit of 5 BC breaks seems completely arbitrary. Why not 6? Or 4? There's no rational basis for that number that I can see and it could potentially tie our hands when faced with a major revision of some kind that would carry more BC breaks with it. I do like the idea of having a clear, consistent policy regarding BC and version increments. I just don't think the specifics of the proposal are the right way to go about doing that. --Kris