BBC: Breaking Backward Compatibility

Hello Justin & QA folks,
First I have to admit my aim was not so clear in our last
"[PEAR-QA] BC, testing, BBC" discussion... apologies.
As I review the exchanges, the point is more Breaking Backward
Compatibility (BBC).

Again, BBC should never occur, that's the strength of PHP+pear.
But PHP+pear is deeply involved in some hot world
with the web, technologies ... permanently moving.
So as you mentionned, some objectives as security cannot be skipped
and must eventually lead to a BBC.
It's also sometimes very cruel not to get some better existing
functionnality
just because BBCs are to be avoid.

The way to go over BBC by producing a second package as PHPUnit / PHPUnit2
should be absolutely reserved to major review of the package as here,
PHP4-->PHP5.
(in this case PHPUnit5 could have been more "talking")
Just because a second package can double the maintenance.

So, BBC could be admissible in extreme cases.
Sure it must be then documented and exampled.
Possibly some patches, awk ... to semi-automate scripts' adaptation.

More over, as little people read the doc and changelogs,
explicit warnings are to be introduced,
in the sources, but ALSO during the installation/upgrade.
e.g. package "aPckg" was upgraded with a BBC, and install is run:

$ pear upgrade aPckg
WARNING: due to ... reason, aPckg breaks backward compatibility,
so if you use ... feature, take care to adapt your scripts as documented
in ... URL
Go ahead ? (y/n) : _

If this feature allready exists in pear, how to use it ?
Ã_+
bertrand Gugger (toggg)

On Sun, 21 Nov 2004 13:31:35 +0100, bertrand Gugger <bertrand@toggg.com> wrote:
> Hello Justin & QA folks,
> First I have to admit my aim was not so clear in our last
> "[PEAR-QA] BC, testing, BBC" discussion... apologies.
> As I review the exchanges, the point is more Breaking Backward
> Compatibility (BBC).
>
> Again, BBC should never occur, that's the strength of PHP+pear.
> But PHP+pear is deeply involved in some hot world
> with the web, technologies ... permanently moving.
> So as you mentionned, some objectives as security cannot be skipped
> and must eventually lead to a BBC.
> It's also sometimes very cruel not to get some better existing
> functionnality
> just because BBCs are to be avoid.
>
> The way to go over BBC by producing a second package as PHPUnit / PHPUnit2
> should be absolutely reserved to major review of the package as here,
> PHP4-->PHP5.
> (in this case PHPUnit5 could have been more "talking")
> Just because a second package can double the maintenance.
>
> So, BBC could be admissible in extreme cases.
> Sure it must be then documented and exampled.
> Possibly some patches, awk ... to semi-automate scripts' adaptation.
>
> More over, as little people read the doc and changelogs,
> explicit warnings are to be introduced,
> in the sources, but ALSO during the installation/upgrade.
> e.g. package "aPckg" was upgraded with a BBC, and install is run:
>
> $ pear upgrade aPckg
> WARNING: due to ... reason, aPckg breaks backward compatibility,
> so if you use ... feature, take care to adapt your scripts as documented
> in ... URL
> Go ahead ? (y/n) : _
>
> If this feature allready exists in pear, how to use it ?

Sorry Bertrand, but this has been discussed extensively already. The
major version update is there for many reasons that have already been
debated, not the least of which is that people often upgrade without
thinking and end up with unusable scripts. Furthermore many people use
other people's code and if upgrading PEAR breaks that code they may
not be able to fix it.

If updating a package makes lots of BC breaks, then it either hasn't
been architected right or should still be unstable.

--
Justin Patrin

Back on one point, justin,
Justin Patrin wrote:

>On Sun, 21 Nov 2004 13:31:35 +0100, bertrand Gugger <bertrand@toggg.com> wr
ote:
>
> 
>Sorry Bertrand, but this has been discussed extensively already.
>
>
Why no archive of it ? Or where is it?
I agree no BC within a given package name.
Anyway what means BC ?
à+
bertrand