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.
