[Dancer-users] Invalid value for log config

sawyer x xsawyerx at gmail.com
Sat Dec 18 10:48:10 CET 2010


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

That way we'll get people to definitely go over deprecations (when they stay
within the certain branch, such as 1.2x). This means we'll also not confuse
people with "development branch", "stable branch", etc.

The important note here is that *deprecation is not breakage*. We are not
breaking them, only reporting behavior which will be broken in a future
release branch (such as 1.3x, or whichever the next one is).


>
> This also reminds me we need a new permanent branch on the repo, like
> experiemntal, where we will build releases for 1.3
>
> I use such a layout at work, and it works pretty well (with git-flow
> configured in two different ways):
>
>                                         2.0000
> -[ master ]------------------------------|----------------------->
>
> -[ devel ]--+----------------------------+---------------------->
>             \                          /
>              \-[ topic/XXXXX ]--------/
>

This is what I use too and I find it very successful. We're going to start
using it at $work as well.


>
> This layout is good for maintaining one release cycle, but if we want to
> provide development releases in parallel (1.3xxx) we need one more branch.
> Otherwise it will be veru difficult to maintain the 1.2 serie.
>

I am personally against it. I don't want to start seeing multiple versions
of things and start working on backporting features from here and there.
This is a great pain to Linux distributions and it shouldn't be for us.

My view is this:
Every release series should have its own deprecations.
Every release series can break a deprecation that appeared in a previous
release series: 1.2x can break stuff that were deprecated in 1.1x. 1.3x can
break stuff that were deprecated in 1.2x.
There is no "development series" that people will prefer to overlook.
Perl itself will not deprecate in a development and break in a stable. They
will deprecate in the development, carry it to the stable (since the
development is just a development track for the stable release) and then
they will break it in a much futuristic version of the development which
will become the next stable.


>
> My main concer is how can we publish those releases on CPAN...


That's one of my main concerns. Another is how we manage it ourselves. It
seems to me like a development and maintenance nightmare. Another concern is
that people avoid using "development versions" and if that's the place where
we deprecate, they won't even know it.

All the best,
Sawyer. :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.backup-manager.org/pipermail/dancer-users/attachments/20101218/8479ad55/attachment-0001.htm>


More information about the Dancer-users mailing list