Re: [RFC_v3] Handling Backwards Compatibility in PEAR [hopefully the final draft]

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. -- Marshall Roch http://pear.php.net/user/mroch