[Dancer-users] Invalid value for log config
Alexis Sukrieh
sukria at sukria.net
Fri Dec 17 11:10:17 CET 2010
Le 16/12/2010 20:16, sawyer x a écrit :
> Our deprecation policy is to warn of deprecated behavior in the current
> release version in which it was deprecated (1.2x, 1.3x, whatever), and
> die fatally in a following major release.
Indeed.
> This could be added in Dancer 1.3x, including the deprecation warning.
> Then removed entirely in 1.4x.
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).
I like that.
> 1,2x was released only recently, so I'm not sure if we already want to
> deprecate stuff for the big chunk of users we now added (thanks to many
> marketing efforts by the entire community).
As explained, I'd rather never deprecate anything in a stable serie,
1.2xxx is meant to provide bugfixes, documentation updates to the 1.2000
release, only. New features should be added to 1.3xxx in my opinion. And
this is where deprecation can occur.
So:
1.2xxx => stable codebase, no deprecation, no new features
1.3xxx => development codebase, deprecation, new features
I welcome your points of view on this strategy.
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 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.
So the layout could become somthing like this:
2.0000
-[ rel-stable ]-----------------------|----------------------->
-[ dev-stable ]--+----------------------------+---------------------->
\ /
\-[ topic/XXXXX ]--------/
2.000 ... 3.0001
-[ rel-unstable ]-----------------|------------|----------->
-[ dev-unstable ]--+----------------------------+---------------------->
\ /
\-[ topic/XXXXX ]--------/
The rel- branches are used by git-flow to produce releases, the dev-
ones are used as integration branches.
My main concer is how can we publish those releases on CPAN...
>
> Either way, there's no reason why not to start using this structure
> manually and implement the new strictures in a new branch to be merged
> on whichever release in which we want it. I'll try to get on it sometime
> soon.
Yes, that's another way of doing it, maybe more simple: use some
parallel branches and merge them when we want, but I fear this will
become very hard to maintain over time, if we want 1.2xxx to remain stable.
Feel free to coment on that idea.
Regards
--
Alexis Sukrieh
More information about the Dancer-users
mailing list