On Nov 6, 2014 11:46 AM, "Andrea Faulds" <a...@ajf.me> wrote: > > > > 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? > > --
We have minor BC breaks (new errors. Slight behavior changes due to bug fixes). But globally no, it makes end users work harder for migration, even worst for distros. See Debian f.e., they boost the adoption speed now, we finally see some results, within the 2-4 years plan we had back then. I could not imagine a worst time to rollback what we defined.
