Re: Concerning: New guidelines for BC breaking releases

Hi Wolfram, If the public API for MDB_QueryTool does not change, you do not need to release a new package name of MDB_QueryTool2. Instead, simply release a new version that requires MDB2 instead of MDB. Of course, if you still wish to support MDB for several releases, then it would make sense to release MDB_QueryTool2, but the whole point of releasing MDB2 is to deprecate MDB1. In other words, let's look at this from another point of view - if there was no BC guidelines. MDB_QueryTool depends on MDB. Version 2.0 is released. User X upgrades MDB. User X's application still works, except for some odd behavior in rare cases (MDB 2 is pretty compatible with MDB 1). User X complains of problems with MDB_QueryTool, and eventually figures out the problem - MDB 2.0 breaks BC. In the current system, MDB_QueryTool depends on MDB. when MDB2 is released, User X can upgrade, without affecting MDB_QueryTool-based applications. It makes the question of BC absolutely clear. Is MDB2 BC with MDB? No. Is MDB_QueryTool 1.3 (MDB-based) backwards compatible with *MDB_QueryTool* 1.4 (MDB2-based)? Yes - the only issue then is with subpackages, as you say. All subpackages must be upgraded with the main package. If the public interface to MDB is hidden in the MDB_QueryTool API (i.e. MDB_QueryTool doesn't extend MDB, and you can't call $querytool->mdbobject->mdbmethod()), then there is no BC breakage even if MDB breaks BC. As for your point about subpackages, you hit the nail on the head - this is why I would like to see it implemented ASAP. I also agree that many packages would best be rethought to take advantage of subpackages, in part to help deal with issues like BC and stability incontinuity amongst subsystems, but that is a separate issue. Greg Wolfram Kriesing wrote:

I shortly discussed the new guidlines with Lukas the other day http://pear.php.net/group/docs/20031114-bbr.php Now i was thinking about it, what it means for packages that depend on other packages. I know that those new guidelines are made to solve those problems, here my concern (hopefully you can eliminate it right away). Lets have a look at the following example. I have a package that depends on another package, i.e. MDB_QueryTool. Now MDB releases a new major version (MDB2), to be able to use MDB_QueryTool with the MDB2 it would mean to release a new version of MDB_QueryTool that would be MDB_QueryTool2, right? Ok, that's a simple case, I could live with. But a short time later someone improves MDB_QueryTool and since those updates are quite big a new major version shall be released, that would be MDB_QueryTool3. And if MDB3 comes along the MDB_QueryTool3 has to be updated to MDB_QueryTool4. So we have already 4 major versions, where two of them were only needed due to a depending package:

MDB_QueryTool    actual initial release

MDB_QueryTool2 new major version due to dependency on MDB, which has

                 released another major verison MDB2

MDB_QueryTool3 new features in this package itself, new major version MDB_QueryTool4 same reason as for MDB_QueryTool2 Ok that was a simple case i think. But if you have a package which depends on multiple packages, which release new major versions, the new major versions might increase inflationary and the maintainers always have to watch out and update with every update the package depends on ... or not? The example might be the QueryTool1, which one day might see the light of this world, this would then make it possible to use any data-container abstraction below, i.e. which are (as i think of it now): DB, MDB, DB_ldap, DBA, etc. Now this package has 4 dependencies, and for every new major version of one of those packages it would also need a new major version of QueryTool? The sepearation of sub-packages (such as QueryTool_LDAP, QueryTool_MDB, QueryTool_DB) might handle this? If so then the structure of some packages might need to be rethought. Sorry for this long mail ... I hope someone can eliminate my doubts on the feasablity of the new guidlines, or tell me my worries are not relevant ... just my 2 cents