Hi list,
I'd like to introduce thresholds of backwards compatibility breaks, i.e.
maximum numbers of allowed BC breaks per version.
Lester's mail from a couple days ago had me thinking about the BC breaks
that occur now and then in all the RFCs or all the mails I see these days.
Now, take what I say with a grain of salt, as I've only recently been
involved in this mailing list, as well as in php-src development.
Let me explain my reasoning.
To allow the users of PHP to upgrade their versions, and enjoy the new
features, as well as the security fixes, the least number of BC breaks
should get in the new released versions. That is because a BC break can
lead to many hours of a codebase adaptation, hours that many companies
don't want to pay for if the benefits are minimal.
However, to allow us to evolve the language, BC breaks are a necessary evil.
Another issue is the short timeline of security fixes for the versions. PHP
5.4 will have a total lifetime of 3 years, a very short one for many
people. I'm not advising to increase this timeline, just saying that it
gets in the equation of my discussion.
To mitigate the issue of BC breaks, I think introducing the concept of
thresholds would greatly help the PHP adoption, and mostly upgrades of PHP
versions. If people know that a limited amount of work is going to be
needed when upgrading a PHP version, the upgrades should be done more often.
For example, the following thresholds could be used:
- major BC break: major versions only. 5 major BC breaks allowed per major
version. - minor BC break:
- minor versions: 5 minor BC breaks allowed.
- patch versions: 1 BC break allowed.
Thoughts? Am I thinking too much? Is this idea unfeasible? Is it a good
idea?
Regards,
Florian Margaine
2014.11.05. 21:21 ezt írta ("Florian Margaine" florian@margaine.com):
Hi list,
I'd like to introduce thresholds of backwards compatibility breaks, i.e.
maximum numbers of allowed BC breaks per version.Lester's mail from a couple days ago had me thinking about the BC breaks
that occur now and then in all the RFCs or all the mails I see these days.
Now, take what I say with a grain of salt, as I've only recently been
involved in this mailing list, as well as in php-src development.Let me explain my reasoning.
To allow the users of PHP to upgrade their versions, and enjoy the new
features, as well as the security fixes, the least number of BC breaks
should get in the new released versions. That is because a BC break can
lead to many hours of a codebase adaptation, hours that many companies
don't want to pay for if the benefits are minimal.However, to allow us to evolve the language, BC breaks are a necessary
evil.Another issue is the short timeline of security fixes for the versions.
PHP
5.4 will have a total lifetime of 3 years, a very short one for many
people. I'm not advising to increase this timeline, just saying that it
gets in the equation of my discussion.To mitigate the issue of BC breaks, I think introducing the concept of
thresholds would greatly help the PHP adoption, and mostly upgrades of PHP
versions. If people know that a limited amount of work is going to be
needed when upgrading a PHP version, the upgrades should be done more
often.For example, the following thresholds could be used:
- major BC break: major versions only. 5 major BC breaks allowed per major
version.- minor BC break:
- minor versions: 5 minor BC breaks allowed.
- patch versions: 1 BC break allowed.
Thoughts? Am I thinking too much? Is this idea unfeasible? Is it a good
idea?Regards,
Florian Margaine
You did not specify what does minor/major BC breaks mean, and for
micro/patch you did not specify minor/major.
I guess you meant minor BC break for a micro version, otherwise make no
sense (you can't have major bc break in a micro version but you can add it
with the next micro).
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.
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?
--
Andrea Faulds
http://ajf.me/
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.
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.
Ah, you raise a good point there. It’d be a shame if distros stopped shipping new minor versions of PHP.
Alright then. Perhaps, instead, the solution is more frequent majors, with less BC breaks each.
--
Andrea Faulds
http://ajf.me/
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.
Ah, you raise a good point there. It’d be a shame if distros stopped shipping new minor versions of PHP.
Alright then. Perhaps, instead, the solution is more frequent majors, with less BC breaks each.
Hindsight is a wonderful thing ...
While yes one can run PHP5.2 code on PHP5.4 by hiding everything that
PHP5.4 does not like, in the real world trying to run the two side by
side simply does not work. PHP5.4 was essentially a major version - if
you assume that e_strict failures have to be fixed.
IF 5.4 had been released as PHPNext then those of us who have to live
with the fallout COULD have managed legacy code with PHP5.3.
Yes it is only a number, but a lot more problematic changes WERE pushed
through across those three versions which would have been much safer
handled by removing e_strict from PHP5.4 rather than trying to live with
both versions of PHP.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Lester Caine wrote:
Yes it is only a number, but a lot more problematic changes WERE pushed
through across those three versions which would have been much safer
handled by removing e_strict from PHP5.4 rather than trying to live with
both versions of PHP.
I don't see a problem with regard to E_STRICT. If your code is not yet
strict compliant, simply turn it off for error_reporting:
error_reporting = E_ALL & ~E_STRICT
--
Christoph M. Becker
Lester Caine wrote:
Yes it is only a number, but a lot more problematic changes WERE pushed
through across those three versions which would have been much safer
handled by removing e_strict from PHP5.4 rather than trying to live with
both versions of PHP.I don't see a problem with regard to E_STRICT. If your code is not yet
strict compliant, simply turn it off for error_reporting:error_reporting =
E_ALL& ~E_STRICT--
Christoph M. Becker--
for the record, see https://bugs.php.net/bug.php?id=65322 and the issued
linked from that.
turned out that we had a bug, which prevented the autoload calls inside an
error handler call when the original error was a compile time one.
we have some compile time strict errors about abstract classes which could
have triggered hard-to-debug fatal errors for people(with custom error
handlers which depend on dynamic auto loading) when we madeE_STRICTpart
ofE_ALLin 5.4.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Ferenc Kovacs wrote:
Lester Caine wrote:
Yes it is only a number, but a lot more problematic changes WERE pushed
through across those three versions which would have been much safer
handled by removing e_strict from PHP5.4 rather than trying to live with
both versions of PHP.I don't see a problem with regard to E_STRICT. If your code is not yet
strict compliant, simply turn it off for error_reporting:error_reporting =
E_ALL& ~E_STRICT--
Christoph M. Beckerfor the record, see https://bugs.php.net/bug.php?id=65322 and the issued
linked from that.
turned out that we had a bug, which prevented the autoload calls inside an
error handler call when the original error was a compile time one.
we have some compile time strict errors about abstract classes which could
have triggered hard-to-debug fatal errors for people(with custom error
handlers which depend on dynamic auto loading) when we madeE_STRICTpart
ofE_ALLin 5.4.
Thanks for pointing this out -- I have not been aware of the issue. Of
course, having had this bug for such a long time is unfortunate, but it
seems to me a viable userland workaround for not yet "strict" code to
support affected PHP versions would be to pass an appropriate
$error_types argument to the set_error_handler call, e.g.
set_error_handler('my_error_handler', E_ALL & ~E_STRICT);
--
Christoph M. Becker
Ferenc Kovacs wrote:
On Thu, Nov 6, 2014 at 12:16 PM, Christoph Becker cmbecker69@gmx.de
wrote:Lester Caine wrote:
Yes it is only a number, but a lot more problematic changes WERE pushed
through across those three versions which would have been much safer
handled by removing e_strict from PHP5.4 rather than trying to live
with
both versions of PHP.I don't see a problem with regard to E_STRICT. If your code is not yet
strict compliant, simply turn it off for error_reporting:error_reporting =
E_ALL& ~E_STRICT--
Christoph M. Beckerfor the record, see https://bugs.php.net/bug.php?id=65322 and the issued
linked from that.
turned out that we had a bug, which prevented the autoload calls inside
an
error handler call when the original error was a compile time one.
we have some compile time strict errors about abstract classes which
could
have triggered hard-to-debug fatal errors for people(with custom error
handlers which depend on dynamic auto loading) when we madeE_STRICTpart
ofE_ALLin 5.4.Thanks for pointing this out -- I have not been aware of the issue. Of
course, having had this bug for such a long time is unfortunate, but it
seems to me a viable userland workaround for not yet "strict" code to
support affected PHP versions would be to pass an appropriate
$error_types argument to the set_error_handler call, e.g.set_error_handler('my_error_handler',
E_ALL& ~E_STRICT);--
Christoph M. Becker
the bug is already fixed by Nikita, I only brought it up, as an example
that migrating to 5.4 and the fact that we included E_STRICT to E_ALL could
indeed cause fatal errors for some application.
ofc after you realize the issue, there were a couple of ways to mitigate it
(the easiest is to change your php.ini to remove E_STRICT from
error_reporting or changing your error handler to not care about these kind
of errors or to not depend on the availability of your autoloader).
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Yes it is only a number, but a lot more problematic changes WERE pushed
through across those three versions which would have been much safer
handled by removing e_strict from PHP5.4 rather than trying to live with
both versions of PHP.
I don't see a problem with regard to E_STRICT. If your code is not yet
strict compliant, simply turn it off for error_reporting:error_reporting =
E_ALL& ~E_STRICT
I get tired say this !!!
The problem is trying to maintain TWO totally incompatible code bases
side by side. It is all to easy to have a wrong setting, or pick up a
'e_strict' version library with a not yet fixed set of code!
If many of the libraries I work with had NOT been updated there would be
less of a problem, but the ONLY way to prevent white screen sites is to
get rid of all of the old code ... which is still unfortunately work in
progress ...
Keeping the non e-strict code on a PHP5.2 powered server and only using
e_strict compliant on the PHP5.4, we maintain stable operation, but
ISP's are upgrading shared hosting and that is where ring fencing the
legacy code is time consuming and detracting from getting code cleaned up.
And switching off error reporting only adds to the problems recovering
sites which have gone down. I know people seem to think that this is not
acceptable on production sites, but my code had always run clean and a
visible error can be picked up and fixed while checking through a large
number of log files across many services to see if there are problems is
not something I want to spend my days doing!
Screwing up the code and then hiding the results is NOT maintaining BC!
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Lester Caine wrote:
Yes it is only a number, but a lot more problematic changes WERE pushed
through across those three versions which would have been much safer
handled by removing e_strict from PHP5.4 rather than trying to live with
both versions of PHP.
I don't see a problem with regard to E_STRICT. If your code is not yet
strict compliant, simply turn it off for error_reporting:error_reporting =
E_ALL& ~E_STRICTI get tired say this !!!
The problem is trying to maintain TWO totally incompatible code bases
side by side. It is all to easy to have a wrong setting, or pick up a
'e_strict' version library with a not yet fixed set of code!
If many of the libraries I work with had NOT been updated there would be
less of a problem, but the ONLY way to prevent white screen sites is to
get rid of all of the old code ... which is still unfortunately work in
progress ...
Well, that's life. If you have a car that needs leaded fuel, you might
have a hard time to drive it nowadays.
Keeping the non e-strict code on a PHP5.2 powered server and only using
e_strict compliant on the PHP5.4, we maintain stable operation, but
ISP's are upgrading shared hosting and that is where ring fencing the
legacy code is time consuming and detracting from getting code cleaned up.
Actually, you shouldn't have to have "strict" compliant code for PHP
5.4. Ferenc pointed out a particular bug, where "non strict" code would
throw a fatal error, but this has been fixed, and there are several
general workarounds.[1] If there are other bugs in this regard, you
ought to report these.
And switching off error reporting only adds to the problems recovering
sites which have gone down. I know people seem to think that this is not
acceptable on production sites, but my code had always run clean and a
visible error can be picked up and fixed while checking through a large
number of log files across many services to see if there are problems is
not something I want to spend my days doing!
Nobody suggested to switch off error reporting. IMO, E_STRICT is
supposed to be a weak form of E_DEPRECATED, i.e. a hint for the
developer to modernize the code in the near future. Until this can be
done, it seems to be perfectly fine to suppress these warnings. When
the developer finds the time to fix the outstanding issues, running the
test suite in a development environment should catch most (if not all)
of them. If there is no test suite, the developer is likely to be out
of luck anyway, IMHO.
Screwing up the code and then hiding the results is NOT maintaining BC!
Apparently, the inclusion of E_STRICT to E_ALL wasn't supposed to screw
up anything.
[1] CAH-PCH54+xOPYcpW8MPB45mjKSfbRMpgYbj=wPwBnP7_ymYdCQ@mail.gmail.com
--
Christoph M. Becker
Nobody suggested to switch off error reporting. IMO,
E_STRICTis
supposed to be a weak form of E_DEPRECATED, i.e. a hint for the
developer to modernize the code in the near future. Until this can be
done, it seems to be perfectly fine to suppress these warnings. When
the developer finds the time to fix the outstanding issues, running the
test suite in a development environment should catch most (if not all)
of them. If there is no test suite, the developer is likely to be out
of luck anyway, IMHO.Screwing up the code and then hiding the results is NOT maintaining BC!
Apparently, the inclusion ofE_STRICTtoE_ALLwasn't supposed to screw
up anything.
Incremental changes from one version to the next may work for some
people. The problem is bringing Pre-5.2 code forward so that it can
reliably co-exist with already 'fixed' code. Many of the ISP's who tried
simply switching their shared hosting to 5.4 found that so many sites
simply stopped working that they had to revert the change. It is not
'developers' who have to find the time to make legacy code work on
current servers ... it's users who have no idea even where to start!
That their site is simply producing a white screen is not a help so
perhaps the 'defaults' would be better off in favour of the
unsophisticated user rather than something that pleases developers? Not
that it helps anyway since distributions all throw their own two pennies
in, and the 'suggested fixes' fail because the files are not where we
tell them. That is if the hosting company even allow access.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Nobody suggested to switch off error reporting. IMO,
E_STRICTis
supposed to be a weak form of E_DEPRECATED, i.e. a hint for the
developer to modernize the code in the near future. Until this can be
done, it seems to be perfectly fine to suppress these warnings. When
the developer finds the time to fix the outstanding issues, running the
test suite in a development environment should catch most (if not all)
of them. If there is no test suite, the developer is likely to be out
of luck anyway, IMHO.Screwing up the code and then hiding the results is NOT maintaining BC!
Apparently, the inclusion ofE_STRICTtoE_ALLwasn't supposed to screw
up anything.
Incremental changes from one version to the next may work for some
people. The problem is bringing Pre-5.2 code forward so that it can
reliably co-exist with already 'fixed' code. Many of the ISP's who tried
simply switching their shared hosting to 5.4 found that so many sites
simply stopped working that they had to revert the change. It is not
'developers' who have to find the time to make legacy code work on
current servers ... it's users who have no idea even where to start!
That their site is simply producing a white screen is not a help so
perhaps the 'defaults' would be better off in favour of the
unsophisticated user rather than something that pleases developers? Not
that it helps anyway since distributions all throw their own two pennies
in, and the 'suggested fixes' fail because the files are not where we
tell them. That is if the hosting company even allow access.
Well, in the scenario you just described, it is the service provider who
is choosing a) the version of PHP, and b) the default configuration for
users on their system. If somebody is running shared hosting and can't
correctly work with an ini file, and read the release notes from
php.net, they're probably in the wrong business. The users - if they're
not developers - are presumably installing specific pieces of software
created by known 3rd-parties; often, they are doing so using control
panel tools provided by the hosting provider.
The hosting providers have to work with the users to find out if the
software in use will work on a particular platform; but that's a case of
asking the developers and getting an answer "yes" or "no" (or "soon"). A
stronger compatibility between releases makes it easier for the
developers to say "yes", but if there is no developer willing to fix it,
even a single incompatible line (which is an inevitable risk if the
language doesn't completely stagnate) is too much. (If you're willing to
hack the code to make it work, you are, at that point, volunteering as a
developer not a user.)
None of which has anything to do with E_STRICT. Strict notices aren't
indications that behaviour has changed; since we have E_DEPRECATED, they
shouldn't even indicate behaviour is about to change; they just indicate
that there might be a better way of doing what you're doing. I don't
know why you consider them to be in the same category as code
compatibility at all.
--
Rowan Collins
[IMSoP]
None of which has anything to do with E_STRICT. Strict notices aren't
indications that behaviour has changed; since we have E_DEPRECATED, they
shouldn't even indicate behaviour is about to change; they just indicate
that there might be a better way of doing what you're doing. I don't
know why you consider them to be in the same category as code
compatibility at all.
That the traditional method of using PHP5 is no longer politically
correct is the problem here. One can not use both methods of working at
the same time, and since in many cases the third party libraries HAVE
been upgraded and require a later version of PHP even to run, HELPING
users who had perfectly functional sites based on code that was created
using what are still current tutorials but which no longer produce
acceptable code is the main problem here. To pretend that PHP5.4 and
later can safely run legacy code is the problem, and these are BC breaks
that people are pretending have not happened simply because they assume
they can be ignored.
One method of working may be to configure a PHP setup which blocks any
use of e_strict compliant rules and make sure only legacy compatible
code is running. Then legacy sites can be kept running without the
effort of converting the code to clean e_strict compliance. The main
question that should probably be asked is if PHP7 will maintain this
source of confusion or ONLY allow e_strict compliance? Certainly I'd
prefer to see this on plugged. It is all to easy to have some upgrade
override your settings and introduce random breaks in things. THAT is
still a major source of agro, with third party libraries overriding
settings after one has ensured there were set correctly. It's not SIMPLY
ensuring that the hosting is set up correctly, it's the fact that any
library can screw that up!
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Lester Caine wrote on 09/11/2014 22:39:
None of which has anything to do with E_STRICT. Strict notices aren't
indications that behaviour has changed; since we have E_DEPRECATED, they
shouldn't even indicate behaviour is about to change; they just indicate
that there might be a better way of doing what you're doing. I don't
know why you consider them to be in the same category as code
compatibility at all.
That the traditional method of using PHP5 is no longer politically
correct is the problem here. One can not use both methods of working at
the same time, and since in many cases the third party libraries HAVE
been upgraded and require a later version of PHP even to run, HELPING
users who had perfectly functional sites based on code that was created
using what are still current tutorials but which no longer produce
acceptable code is the main problem here. To pretend that PHP5.4 and
later can safely run legacy code is the problem, and these are BC breaks
that people are pretending have not happened simply because they assume
they can be ignored.
Yes, many pieces of software have a minimum PHP version to run, often
because they make use of useful new features, e.g. namespaces and
closures from PHP 5.3.
This is a very different kind of compatibility from old software not
working on newer versions of PHP; it is up to the projects in question
to decide which versions to support.
One method of working may be to configure a PHP setup which blocks any
use of e_strict compliant rules and make sure only legacy compatible
code is running. Then legacy sites can be kept running without the
effort of converting the code to clean e_strict compliance. The main
question that should probably be asked is if PHP7 will maintain this
source of confusion or ONLY allow e_strict compliance? Certainly I'd
prefer to see this on plugged. It is all to easy to have some upgrade
override your settings and introduce random breaks in things. THAT is
still a major source of agro, with third party libraries overriding
settings after one has ensured there were set correctly. It's not SIMPLY
ensuring that the hosting is set up correctly, it's the fact that any
library can screw that up!
There should be no problem with fixing some strict notices and not
others, so I don't understand your comment on blocking e_strict
compliance in order to run legacy code. Can you give an example of a
notice where you would want to actually prevent compliance, rather
than just ignoring the notice if you don't have time to fix it?
Again, updating code may well raise the minimum required PHP version,
but this is much more likely to be because the developer wants to take
advantage of new features, not because they're trying to run with no
strict notices.
--
Rowan Collins
Senior Developer | CWT Digital
t. 0845 456 0070 *w.*cwtdigital.com <http://www.cwtdigital.com/
2014.11.06. 2:46 ezt írta ("Andrea Faulds" ajf@ajf.me):
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.
2014.11.06. 2:46 ezt írta ("Andrea Faulds" ajf@ajf.me):
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
Hi,
Thoughts? Am I thinking too much? Is this idea unfeasible? Is it a good
idea?
Have you missed:
https://wiki.php.net/rfc/releaseprocess
?
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
Hi!
- major BC break: major versions only. 5 major BC breaks allowed per major
version.
I'm not sure how such numbers make sense. Why 5 and not 3 or 7 or 17? If
that breaks your code, even one is too much. If your code is not
affected, why would you care if it's 5 or 15 or 150? I'm afraid this
would just devolve into semantics discussion and arguments about how to
count them and why it can be 5 but not 6. I don't see any reason to put
any numeric value on it.
- minor BC break:
- minor versions: 5 minor BC breaks allowed.
- patch versions: 1 BC break allowed.
Patch & minors should not have BC breaks, excepting bugfixes where it is
inevitable. Of course, it is an ideal situation, and in practice we may
miss stuff, or we may not have a choice, or we may prefer BC break to
the alternative. But again I don't see how putting a number on it helps
something. If we have two cases where we must have BC break and not one
- and we absolutely sure we have no better choice and that's what we
have to do - how having arbitrary limit of 1 would help?
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/