Stefan Neufeind [2009-07-25 14:36 UTC] The original intention was to be able to maintain (and e.g. send fixes etc.) for two separate trains/major versions. Another special case was redesigning the API for a cleaner PHP5-interface, which would still need a new major version as long as the package is not in alpha-stage anymore (because of BC-break).
As long as a dev is sure about the implications of his decision I agree with Sebastian that the proposal is a viable solution now that PHP4 is dead since so long. And if package.xml deflects the minimum php-version needed, that should prevent to break peoples existing installations.
Till Klampaeckel [2009-07-25 16:39 UTC] +1
I think you could still maintain two branches -- if necessary.
Say, the current package version (e.g. Net_SMTP) is 1.3.3. If you wanted to release a PHP5-only package, just start off with the release Net_SMTP 2.0.0-alpha (without the name change). Major version, BC break allowed. And on 1.x, you still have plenty of room to provide patches etc. for years to come.
I guess in the end it's a matter of organizing releases on the pear website and the channel. It looks like that could be a reason for separate package name (e.g. Net_SMTP vs. Net_SMTP2). I haven't checked though, nor do I know the internals so this could work already.
Brett Bieber [2009-07-25 17:50 UTC] I think the title of this RFC is incorrect. I'm not aware of any requirement to rename a package when migrating from PHP4 to PHP5 - the standards state that once a package has reached 'stable,' breaking backwards compatibility requires changing the package name. I don't believe this has anything to do with what PHP version the package requires.
Of course the minimum PHP version listed in the package.xml for an individual release can eliminate the risk of upgrading to a package that uses different features of PHP. But the minimum PHP version in package.xml has no bearing on the code written by the end users of a package whom have written code to an exposed api.
Utilizing the API version of the package release in combination with the minimum PHP version, as suggested in Greg's proposal sent to the PEAR-DEV list, is the correct way to handle this in my opinion. But this would require altering the PEAR installer to act like Pyrus/PEAR2 (introducing the 'paranoia' setting).
This would warn end-users before upgrading a package with a major api version number change, and would eliminate backwards compatibility fears when blindly upgrading a package.
See this for details:
http://markmail.org/message/ftq47ffckg2uhkl7
I think Greg's proposal is the best way to get what we all want — accommodating the backwards compatibility concerns while allowing progressive development of existing and future packages.
Christian Weiske [2009-07-26 09:01 UTC] Could you please post a link of that rule you are trying to deactivate?
Sebastian Nohn [2009-07-26 10:20 UTC] Helgi claimed so in http://pear.php.net/bugs/bug.php?id=16442
Christian Weiske [2009-07-26 12:33 UTC] PEAR's current version naming standard is in the manual:
http://pear.php.net/manual/en/rfc.version-naming.standard.php
It states that "The next major version is MyPackage2" - that's the issue we are facing here.
The original reason for that rule is that the PEAR installer does not know when BC breaks occur. Package version does not sufficently express them, and the api version in the package is not used by the PEAR installer in any way.
Thus, to prevent BC breaks through the normal upgrade process, it was decided to rename the package when doing a major overhaul like moving from PHP4 to PHP5, breaking BC.
This rule is not neccesary anymore when using Pyrus instead of the PEAR installer, because Pyrus understands the api versions and errors out when BC breaks occur, preventing the user from damaging his applications. So, for PEAR1 packages, the rule should be followed. On PEAR2 packages, it is to be dropped and ignored.
Alexey Borzov [2009-07-27 10:02 UTC] The title is misleading, it *is* possible to migrate a package to PHP5 either
1) Without breaking BC or
2) In the part of the development cycle where BC breaks are allowed
and no renaming will be needed.
Also PEAR2 will (hopefully) take care of the whole Foo_Bar2 business, so this is not quite needed.
Michael Gauthier [2010-01-17 05:33 UTC] The current PEAR requirement to suffix a package name with "2" is not limited to packages changing from PHP4 to PHP5. The current rule applies any time a BC break is made to a stable package.
I'm not sure this rule will ever be able to be lifted for stable packages. The problem is sometimes you need to have both the old version and new version of the API installed and used in one application.
For example, the Services_Amazon_S3 package dependeds on HTTP_Request2 while Services_oAuth depends on HTTP_Request. If this proposal were accepted, it would not be possible to use S3 and oAuth from PEAR in the same application.
There was a PEAR RFC drafted for this proposal which I am not currently in favor of approving for this reason: http://wiki.php.net/pear/rfc/pear2_versioning_standard_revision
This thread on PEAR-dev details my concerns: http://thread.gmane.org/gmane.comp.php.pear.devel/47696/focus=48629
Also note the current rule does NOT apply to unstable packages. If there is a PHP4 compatible package in PEAR that is not marked as stable, it can be moved to PHP5-only code without changing the package name.
|
