[Dancer-users] Invalid value for log config

[Gabor Szabo]

On Sat, Dec 18, 2010 at 11:48 AM, sawyer x <xsawyerx at gmail.com> wrote:
> On Fri, Dec 17, 2010 at 12:10 PM, Alexis Sukrieh <sukria at 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