On 18 December 2010 12:31, Alexis Sukrieh <sukria@sukria.net> wrote: 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.
I think everybody agree about that. A branch is created from the master release, to apply bug fixes and release minor versions.
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.
Agreed, but again, I think there is nothing wrong about creating a new branch from 1.2. I think it's a good thing. I am completely happy with this model as long as the branch is created *from* 1.2 to apply maintenance fixes. It's different from having an other unlimited "branch" without starting point, like "unstable-dev".
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?
I don't think there is a
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