Hi,
Ferenc, that does seem like a good middle ground to me, though I think it
would have to be "guaranteed" that major releases would be on a 3 year
rolling schedule from the next major release.
My reasoning for this is that if a major release is delayed, then you have
confusion about when the 3 years starts from or end up with dates changing.
In addition, if a major version was to be skipped then, again, confusion
about when the next version is aimed for (3 years from decision to skip or
6 years from previous major release or something else?).
Just a thought.
On Wed, Nov 20, 2013 at 11:41 AM, Ferenc Kovacs <tyra3l@gmail.com> wrote:
> On Tue, Nov 19, 2013 at 8:16 PM, Nikita Popov <nikita.ppv@gmail.com>
> wrote:
>
> > Hi internals!
> >
> > In a lot of the recent discussions (e.g. the HTTP_RAW_POST_DATA one) I've
> > seen the "we can't break backwards compatibility in PHP 5.x.y" argument
> > crop up again and again.
> >
> > This rather unfortunate formulation takes root in the releaseprocess RFC
> > [1] and drives all discussions of BC issues into a non-constructive
> > direction.
> >
> > Fact is that nearly all changes (by being changes...) break backwards
> > compatibility to some degree [2] and we *do* most certainly allow them in
> > both minor and bugfix releases. Whether they are allowed (and for what
> > version) depends on the *severity* (rather than existence) of the
> breakage.
> >
> > I would really appreciate it if we could move BC-related discussions away
> > from "Does it break BC?" (Yes, it does, in some way) to "How much does it
> > break BC and are we okay with that?"
> >
> > In the context of the HTTP_RAW_POST_DATA discussion this means thinking
> > about questions like a) how much code will be negatively affected, b) how
> > hard will it be for the code to be fixed and c) do the benefits in
> > performance, memory usage and/or functionality (significantly?) outweigh
> > the inconvenience of code-adjustments?
> >
> >
> >
> > As some people have a hard time understanding that small BC breaks are
> > introduced routinely and intentionally, some examples of changes that are
> > considered "generally okay" for bugfix and minor releases:
> >
> > Bugfix x.y.z -> x.y.(z+1):
> >
> > * Addition of new functions, if the function name is unlikely to already
> > be in (unconditional) use. E.g. the addition of getallheaders() for the
> > built-in webserver in PHP 5.5.7.
> > * Changes in the behavior of functions where a) the old behavior was
> > considered buggy and b) not much code was relying on the old behavior
> (most
> > bug fixes minus crashes fall into this category)
> >
> > Minor x.y.0 -> x.(y+1).0
> >
> > * Addition of new keywords, if the keyword is not commonly used in code
> > already. (E.g. "yield", but not "user").
> > * Deprecation of functions or language features. In practice deprecation
> > of heavily-used components like ext/mysql is *one hell* of a BC break,
> but
> > we're okay with it for minor versions. (This also includes addition of
> > other non-fatal errors)
> > * Removal of long-deprecated or little used functionality. E.g. the logo
> > guid functions were removed in 5.5.
> > * Changes in the behavior of the language where a) the old behavior was
> > considered buggy and b) not much code was relying on the old behavior.
> >
> > Thanks,
> > Nikita
> >
> > PS: I think that it would be nice to adjust the releaseprocess RFC to
> > clarify this point, to make things clearer for both contributors and
> > end-users. The current promise sounds a lot like "You can just update
> from
> > 5.4 to 5.5 and won't need to make any code changes", but for any
> > non-trivial (legacy) codebase that's pretty far from the truth.
> >
> > [1]: https://wiki.php.net/rfc/releaseprocess
> > [2]: http://xkcd.com/1172/
> >
>
>
> Hi Nikita,
>
> Thank you for your feedback on the issue.
> Personally I think that our current release process RFC only solves half of
> the problem.
> We were seeing slow adoption rates for new versions and also users
> complaining about every second micro version breaking backward
> compatibility (some of those concerns were ofc. magnified), but having the
> current release process, which promises complying with the current best
> practices, aka semantic versioning (http://semver.org/).
> I think that the rfc should be a bit more descriptive/exact about what do
> we mean by API/ABI BC break, and bugfix, but otherwise it is fine.
> Additionally it is also defines the yearly release cycle, and the two+one
> year support cycle, which is also quiet nice.
> From the userland POV, we covered all the bases, you know what you can
> expect from a release and when can you expect a new release.
> What we didn't cover is the issue of the major versions.
> Currently there is no way to plan any change which requires a BC break and
> doesn't qualify as a bugfix.
> This causes issues like:
>
> - people are frustrated that there is no way to tell when or if a
> contribution will make it into a release if it requires a BC break
> - which causes people to try and force/sneak in BC breaks into minor
> versions
> - which causes additional stress and work to the RMs and those who are
> trying to follow the process, and also erodes the users trust in the new
> model when they see that we still don't follow the rules we put forward
> to
> ourselves.
> - we don't have a place/branch to accept backward incompatible changes,
> because we have no way to tell beforehand, whether the next version
> will be
> a minor or major, everything goes into master, then we end up in a
> situation, when branching out the new minor version is a PITA, because
> it
> could have everything from master, except those dozend of commits which
> are
> related to that single backward incompatible change that we have there..
>
> We had this discussion before, and I agree with Rasmus and co. that in an
> open-source, volunteer-based project we can't really tell beforehand, that
> what will be in the next version, before the work is actually done
> (otherwise we end up with another PHP6, where there a bunch of promises
> what should be there, and the release is stucked when some milestone
> feature gets delayed/abandoned), but I do think that we could do stuff like
> communicate that we can have a major release like in every 3 years, which
> will be supported at least for 3 minor releases.
> That way both the userland and the core developers could have some kind ETA
> for getting there changes, and we could always skip/delay the major version
> if there is nothing which would require a major release(albeit I don't
> think that we would ever run short of backward incompatible changes).
>
> tl;dr: I would like to stick with the current release process and don't
> start using the previous bad process/exceptions as an excuse to keep adding
> backward incompatible changes to our minor versions, but I would like to
> extend the release process to cover the lifecycle of major versions.
>
> --
> Ferenc Kovács
> @Tyr43l - http://tyrael.hu
>