RE: [PEAR-DEV] [RFC_v3] Handling Backwards Compatibility in PEAR [hopefully the final draft]

On 26 Sep 2003 at 8:58, Lukas Smith wrote: > I think we have one problem with the RFC since two things are a bit > mixed and maybe we should discuss them separately. > > 1) the ability to run major versions of packages side by side > 2) if a rewrite is a major version bump > > it seems that 2) is Alexey's major concern in the debate for example > and I think its affecting his opinion on 1). I see the problem that completely rewriting a package from scratch and releasing it as the same major-version is a problem because the already "stable" package should then again to through at least a beta- state (b1 added to the version number or whatever). But somewhere in the RFC we demanded that a stable package is not declared beta within the same branch, right? Do we need to demand this? Or could the installer simply take care of this (if prefered state is stable, don't install new beta)? This way we would not need a new major version if the API completely remains. If there is need for a new major-version I'd suggest to always branch off a new package so that Foo in version 2.0 will always be Foo2 and that there is no Foo and Foo3 whereas Foo in version 2.0 would have been Foo, but version 2.0. Then there would exist Foo and Foo3 some time but no Foo2. This might lead to a lot of confusion. Stefan