[Dancer-users] Dev and Release workflow ( was: Re: Invalid value for log config )

[damien krotkine]

*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 at 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 at perldancer.org
> http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.backup-manager.org/pipermail/dancer-users/attachments/20101217/89c925e5/attachment-0001.htm>