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