RE: [PEAR-DEV] [RFC2] Handling Backwards Compatibility in PEAR

I wrote before, and willl stick by it, that BC breaks, major, minor, or half way in between should only be allowed in the case of bug fixes or security problems. Period. Once a release has been made, no new features, API changes, or doh!s should be fixed unless they are a result of a bug or security problem. They should be fixed/added/addressed in the next major release. This is simple package management in an open environment. API should be set in major releases. I would buy into the three step versioning. Mainly with the "hard set rules" on the major version, then the second and third octet for communicating changes In other words: FOOw x.y where: w reflects API version allows API Additions allows ANY BC breakage not related to bugfixes/security fixes allows ANY BC breakage releated to bugfixes/aecurity flaws x reflects new features allows API Additions DOES NOT allow BC breakage not related to bugfixes/security fixes or major BC breakage y relects bugfixes/security fixes allows only minor BC breakage directly related to fixing bugs or addressing security flaws Thanks, Rob > -----Original Message----- > From: Greg Beaver [mailto:greg@chiaraquartet.net] > Sent: Saturday, September 20, 2003 11:46 AM > To: Stefan Neufeind > Cc: pear-dev@lists.php.net; Alexey Borzov > Subject: Re: [PEAR-DEV] [RFC2] Handling Backwards Compatibility in PEAR > > > > > Stefan Neufeind wrote: > > >Well, if we (Alexey and me) mis-understood each other *that* much > >then Greg you're right ... and my apologize go to Alexey for mis- > >understanding him. The way I understood Alexey was that "a complete > >API break" or "complete rewrite" would require a new major version. > >But "minor breaks" could be solved also inside the same major > >version. And that's what lead me to the point of thinking "hmm, > >renaming a function is only a minor break so he didn't want to bump > >the major version so users might get into problems". > > > I didn't read this in what Alexey wrote, I just figured Alexey was > defining version numbering. The problem of minor BC breaks is the > reason why it needs to be possible to do this versioning scheme: > > Foo 1.0.0 > Foo 1.0.1 bugfixes > Foo 1.1.0 feature additions > Foo 2.0.0 minor BC breakage - the package is essentially the same, users > must do text search-and-replace for a few methods > Foo 2.1.0 etc. > Foo3 3.0.0 MAJOR BC breakage - whole API is reworked to give major new > features not possible with Foo 2.x, give users whose apps only need the > functionality of Foo 2.x no need to rewrite their apps, and allow newer > code to co-exist if necessary with older code until the old code is > rewritten in the future. > > In this way, minor BC breakage doesn't require any change to namespace. > > This is also why I wrote the patch to check on major version upgrades > > Greg > > -- > PEAR Development Mailing List (http://pear.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php >