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

[Alexis Sukrieh]

Hi,

I don't have much time these days to follow everything that happens 
around Dancer and I must say I'm very glad of that, because it meas the 
project I've started in summer 2009 starts to grow by itself. As a 
project leader, nothing can be more pleasant.

I take the opportunity to thank very much all the contributors that 
worked on Dancer, and more precisely the members of the core team who do 
a great job: SawyerX, Franck Cuny and David Precious.

On the other hand, we have a very important choice to make, about how 
Dancer's developement and releases will be handled. I'm not pleased with 
the startegy we have yet, because it's not working. Yes, it is *not*.

First, what we have:

Dancer 1.2xxx is the current "stable" release of Dancer, and we 
announced in the first calendar article we will _provide stability 
support_ for it.

We want to provide new features, refactoring and experimental stuff in 
the 1.3xxx series.

If we choose to do that, I'm sorry to say we have no choice but creating 
a new branch to reflect changes that will have to occur in the 1.2 serie.

Let me take an example:

Let's say someone has 1.2003 in production, they ar happy with it and 
want to make sure nothing breaks in their app. So they trusted us when 
we said 1.2xxx will remain stable (only bugfix updates).

Then, we upload 1.3001 to CPAN.

OK, now imagine a critical bug is found in 1.2003.

...

How do we fx it in GitHub? Our master branch now reflects the 1.3001 
release. That sucks. We have to create a branch from the 1.2003 tag, 
maybe "1.2-maint" and start producing bugfix release from there.

==> My point is that we CANNOT provide stability release for 1.2 WITHOUT 
this new branch. It's just impossible.

If we solve that, we also have a situtation regarding CPAN uploads: if 
1.3001 is uploaded on CPAN, how do I publish 1.2003 releases?

Again, all this situation is there because we said publicly in the first 
place that 1.2xxx will be maintained for stability. I think it's a good 
idea to do that, it shows that Dancer takes production matters 
seriously, but if we want to do that, we have to understand all that it 
means.

Furthermore, I think I have a good overview of the situation here, 
because my job at @paidwork was exactly that: providing a set of tools 
and startegy for release cycle with maintenance branches, based on git + 
git-flow. So I think I see all the implications.

If we want to do that, the git solution is the following layout:

master ------------> last release (1.3001)

devel  ------------> integration branch for building
                      master releases(see git-flow)

topic/* -----------> temporary features branch for devel
                      (see git-flow)


This layout works great for one release cycle, but as explained before, 
we want to provide 2.

So we should add:


maint/1.2 ----------> originate from the tag 1.2003 and contains new
                       releases of 1.2
                       This branch only contains merge of topic branches
                       that are bug fix or updates for the 1.2 serie.
                       They are also backported in devel as well.


Trust me, this works and is not as complicated as you may think in the 
first place, with a core-team that know it well.

Remember we have GitHub pull-requests with us, for handling 
contributions (this just concerns the job of Dancer's integrators, 
namely the core-team).

As the project-leader of Dancer, I'm saying all this not to be the 
"bad-guy in the party" or anything, but just because I really appreciate 
all the work we did together, and I don't want us to go in a wall with a 
mess in our development process.

And I think that we are, if we dont take good decisions now.

I hope things are clearer now, and that you get my point of view.

Note that I don't have a solution for CPAN uploads, but dams told me the 
Catalyst team has a similar concern, maybe we should look at how they do.

Best Regards,

-- 
Alexis Sukrieh