[Dancer-users] Invalid value for log config

[Alexis Sukrieh]

On 18/12/2010 13:13, sawyer x wrote:
>
>     In many projects even numbers represent stable version and odd numbers
>     represent development version.

I agree with Gabor.

>     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
>
>
> We already use _01, _02 and so on as development versions.

Well no. We use XXX_XX releases as pre-releases of non-developer 
versions, just in order to make sure the test suite passes everywhere.

So if we want the following to be true:

     "The entire 1.2xxx release series promises not to break your app,
     unless it is a critical fix (such as a security concern - which is
     business-critical). You are assured stability in upgrading to any
     1.2xxx release."

Then, we will HAVE to be able release both 1.200X_XX releases AND 
1.3xx_XX releases.

We cannot provide a 1.2 releases serie in parallel to a 1.3 one without 
forking the releases flows, I really don't see how we could...

Please tell me if you have a magic solution I have not. I'd be happy to 
read it and to rethink my conclusions.

We have IMHO two paths we can take:

1. We don't say that 1.2 will live as long as 1.3001 is out (and that 
makes the calendar lie); and we continue our workflow as always, with 
ONE release branch. And there, problem solved.

2. We want to do what is explained in the calendar, and allow users to 
stick with 1.2xx version until 1.4 is out for instance (I like very much 
that idea personnaly). But we have to provide then a new release cycle, 
for the reasons I explained in my previous mail (hotfix issues and so 
on, please read it if you didn't).


> I see it as an added tier and without good reason.

Well, there is a reason you cant ignore: provinding a maintenance 
release series implies that you can do final and developer releases for 
that serie in parallel to the master serie.

Again, all this situation is there because of what we said in the 
calendar, so either we choose to follow what we said, and we take 
conclusions on that, or we move a step back.

But I really don't see how we could stay in the middle of this.

Frankly.

-- 
Alexis Sukrieh