*top-posting* OK here is a first version of my opinion. You may not like it :) I'm playing a bit of devil's advocate too. We are talking about Dancer : a cool project that is very easy to use, to start with, and to build your web platform on. I suggest we try to have the same goal for the development and release environment. So there should be no thinking needed when getting a production release on CPAN, and there should be freedom to hack Dancer code 1/ About CPAN releases : I don't think it's useful to have even and odd releases visible for user (aka on CPAN). Either you have something stable you are happy to ship for production use, and you ship it on CPAN, or you don't ship it at all. Having multiple versions on CPAN with odd numbers, etc, will make it more difficult for users to know which one is good for them. Especially because we don't have strict deadlines. So basically, you may end up in 2014 having 1.4 good and stable since feb 2011 but with an old set of features, and 1.5 containing a bunch of new features, but considered unstable. Basically that's the debian approach (*ouch* don't *ouch* hit me! ), and release management and cycles will become a nightmare. So I'm in favor for 1.2 and 1.3 being both stable versions. And only these to be released on CPAN. 2/ About github : The problems we have currently is that : - the dev manager (sawyer for now I think - congrats) has to choose what to pick up from developers branches. He has to handle conflicts, test failing and so on, if the branch has been made long time ago - the developer is frustrated because he doesn't see his code merged in devel before long ( he's being said "after we release 1.2", "after advent calendar", "after we have talked about it", etc) To fix these issues, I propose that we keep devel and master as we have them, but add a new *experimental* branch. It's a big open sandbox : - this experimental branch is recreated from devel each time a new stable version is done, or when the dev manager thinks it's too messy - Dancer developers are trusted : they can push new branches and *merge* them into experimental, as long as they don't use rebase, and that the test suite passes - the dev manager picks up branches he likes from the experimental branch When new versions are released, the sandbox is cleaned up, experimental branch is wiped out and recreated from devel, and a next cycle can occur. Benefits : - developers can see their work in action in the code. Other dev will get the features immediately, they will react quickly : either they like it, or they don't, so they argue with the developer that merged the change. But they are not frustrated anymore - dev manager has less work to do regarding conflicts and merge issues, because developers take care of test passing when they merge - dev manager has an easy way to clean up things : wipe out experimental and recreate it Because we use git, developers don't loose their work when experimental is wiped out : they have their own branches. All they have to do is to rebase them on the new experimental branch, and fix tests / conflicts if any. This way of doing is from a simplified version of previous work experience. Just my 2 cents, may be useful for the discussion. Remember, developers freedom is important :) On 17 December 2010 11:10, Alexis Sukrieh <sukria@sukria.net> wrote:
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
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users