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

[damien krotkine]

On 18 December 2010 12:31, Alexis Sukrieh <sukria at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.backup-manager.org/pipermail/dancer-users/attachments/20101218/3eeaef09/attachment.htm>