On Sat, Dec 18, 2010 at 11:48 AM, sawyer x <xsawyerx@gmail.com> wrote:
On Fri, Dec 17, 2010 at 12:10 PM, Alexis Sukrieh <sukria@sukria.net> wrote:
I agree, using the 1.3 releases serie for deprecating stuf inn 1.2 sounds good. Making them fatal error in 1.4 makes sense.
This strategy sounds good: release series with even number (1.2, 1.4, 1.6, ...) always contain stable features, intermediate series can deprecate things in the previous serie (1.3 can deprecate, with warnings, stuff in 1.2).
The trick here is to get people to actually go through the 1.3 release branch or they will be not be able to transition easily. If they go through deprecating releases they'll get warnings on what to fix. If they don't, things will just break.
This is the downside of it and usually why I don't support such behavior.
So:
1.2xxx => stable codebase, no deprecation, no new features 1.3xxx => development codebase, deprecation, new features
Like I said, the problem here is that people will generally prefer to avoid development branches, meaning that jumping from one stable release to the other (without the deprecation stage) will leave them broken.
I suggest we start deprecating now. 1.2xxx => stable + deprecations 1.3xxx => new release, stable + breaking old deprecations
In many projects even numbers represent stable version and odd numbers represent development version. So why not: 1.2 stable 1.3 development , warn for deprecations A 1.4 stable, warn for deprecations A 1.5 development , exception for deprecations A + warn for deprecation B 1.6 stable, exception for deprecations A + warn for deprecation B 1.7 development , exception for deprecations B + warn for deprecation C 1.8 stable, exception for deprecations B + warn for deprecation C Gabor