Re: Breaking BC / Changing API / Deprecating

On 7/19/05, Joe Stump <joe@joestump.net> wrote: > > Yes, but this policy was put in place to save the users. If they > > upgrade to a new version of a package with BC breaks then their > > scripts will stop working. Remember that PEAR is sometimes installed > > by people who are simply getting dependencies to another package. They > > could easily, unwittingly, install a version which is incompatible. > > This is (part of) why BC rules exist. > > Maybe I'm the only one that reads the CHANGELOG before updating? > Also, as long as the package that depends on the BC broken package > has been updated there shouldn't be any problems upgrading (as long > as the depended upon package isn't used elsewhere). > > I guess I just don't see a huge need to "save the users" when these > people would have had ample knowledge ahead of time, a CHANGELOG, > etc. I'm not talking about rolling out a 2.0.0 release without first > making it 2.0.0 alpha -> 2.0.1 beta -> 2.0.2 stable. They'd have > plenty of time to fix their code. I'm not talking about developers I'm talking about the *users* of the programs which rely on PEAR packages. These people can quie easily upgrade their PEAR installation without knowing anything about PHP or the scripts they're using. > > > > > The Linux kernel is an etirely different beast. First of all you have > > to know (somewhat) what you're doing to upgrade to a new one. It's not > > as simple as "pear upgrade-all". Second, the kernel's API doesn't > > really change. At least not the exposed API. The internal API can > > change in all sorts of ways and it won't affect programs which run on > > top of it. If an external change is made a huge deal is made out of > > it. > > Have you used make-kpkg under Debian? Also, you're basically saying > that since PEAR users are too stupid to understand that sometimes > API's change with major point releases that we have to insulate them > with Foo_Bar, Foo_Bar2, Foo_Bar3, Foo_Bar4, etc. Not to mention > things get really hairy when you have packages A and B relying on > Foo_Bar, while packages B and C rely on Foo_Bar2 and then package D > relies on Foo_Bar4. I now have 3 different Foo_Bar packages > installed, each with slightly (not drastically) different API's. It's unfortunate but quite possible that someone win't be willing to change their code for a new version. Some people may like the old version better or the script may not be activeky maintained any more. People still may want to use it, though. And, as Lukas said, if you're making small API changes then your package really shouldn't have been stable. If you're breaking BC then you should either be drsatically changing things (a major revision) or still be in alpha or beta. Also, as Lukas said, BC doesn' thave to be broken for some changes. Optional arguments, new function calls, an option set in the package, these are all ways to introduce new features / functionality which would normally break BC without actually breaking BC. > > > >> > >> I've also heard that it's OK to break BC, change the API, deprecate, > >> etc. as long as it's a major point release (ie. 1.0.0 -> 2.0.0). This > >> makes *much* more sense, IMO. > >> > > > > Yes, this is true. However you're missing that switching to a new > > major revision also means that you release a new package with the new > > version # on the end. > > Are you kidding me? So when Payment_Process hits 2.0 I have to roll > out Payment_Process2 and then when it hits 3.0 I have to roll out > Payment_Process3? So what happens when 5 years from now I'm on > version 5.0? Am I supposed to be supporting this package > indefinitely? And, if not, then can I move Payment_Process5 back to > Payment_Process (as it's not being actively developed or supported I > should be able to totally break it). No, I'm not kidding you. Please check the old discussions and website for more. Then come back and reply. Just because there is an old version of Payment_Process around doesn't mean that it has to be maintained. You can deprecate it for a new version and it can be "hidden" on the website (in a deprecated page) so that we don't clutter our package lists. However, sa I said, some people may still rely on an older version. Take, for example, the major revision from PHP4 to PHP5. It breaks backwards compatibility and has been in alpha and beta for quite some time, however there is still a lot of PHP4 code out there which people still rely on. > > --Joe > > -- > PEAR Development Mailing List (http://pear.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Justin Patrin