Re: [RFC_v3] Handling Backwards Compatibility in PEAR

I think this can be worked into package.xml validation, so pear package will not package a stable release that is < 1.0 I'd like to get input from many people on this question before moving on it - there are a number of packages out there that break this rule which would suddenly not be installable (package.xml validation would fail, aborting install). I don't think it's necessary to add any other restrictions on versioning to the automatic tools. Other disputes should be handled by people, imo. Greg Marshall Roch wrote:

Greg Beaver wrote:

Marshall Roch wrote:

Greg Beaver wrote:

3) release Foo-0.9a - alpha (BC break allowed - but discouraged) 4) release Foo-1.0b1 - beta (BC break allowed - but heavily discouraged) 5) release Foo-1.0 - stable (BC break allowed - but heavily discouraged) 6) release Foo-1.0.1 - stable (BC is not allowed) 7) release Foo-1.1.0 - stable (BC is not allowed)

HTML_Progress-0.6.2 (stable) was just released. In the future, should all stable releases be >= 1.0?

Yes, absolutely. If it ain't 1.0, it ain't stable yet.

Maybe pearweb could include a check when you upload a new release to make sure the version number makes sense. For example, it could make sure that 1.0 is stable, and that all subsequent patches of stable releases are also stable: 1.0 - stable 1.1 - stable 1.1.1 - stable 1.1.2b1 - beta (invalid, throw error) 1.2b1 - beta (allowed, new minor version) 1.2 - stable 1.2.1 - stable I don't see a reason for beta versions for patches/bugfixes. They should be tested enough before release to not need that, and it could prevent people who will only install stable versions from getting a bugfix. Changes major enough to warrant a beta period probably also warrant a new minor version. Maybe it's too many regulations, but it might help maintain a more standard versioning scheme.