cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <...@adobe.com>
Subject Re: too long to package a release?
Date Wed, 02 Jan 2013 19:08:10 GMT
Bumping this thread. I'd like Joe to clarify as well.

On 12/20/12 12:26 PM, "Brian LeRoux" <b@brian.io> wrote:

>Ok, I want to understand this, let me take a stab.
>
>You describe three long-lived branches like this:
>
>- Master: This is stable and frozen on the last tagged release.
>- Dev: the next release to be tagged. Feature branches merged from
>master when confident.
>- Unstable: the current working branch for a particular tag. Feature
>branches merged as needed for collaboration.
>
>Everyone works from local feature branch rebasing and committing to
>master. When that feature branch is considered good enough, it is
>merged into dev, and work continues. Whatever date we happen to pick
>for a release that is what dev becomes, we tag, and move that sha to
>stable if its not an RC.
>
>?
>
>
>
>
>On Thu, Dec 20, 2012 at 10:52 AM, Joe Bowser <bowserj@gmail.com> wrote:
>> I'm OK with this, but I think your example is off:
>>
>> Where n is the current released piece of the software:
>>
>> n.x.x = Stable
>> n+1.x.x = Dev
>> master = Unstable, can have things merged in from feature branches
>>
>> This fully uncouples features from release planning, which is good
>> because it means the release will land in the version when it's ready,
>> and not for any other reason.  I also propose that we keep using the
>> same RC tags and that for a final release we tag it x.x.xFinal.  We
>> still need to tag an RC and re-tag it.
>>
>> Release Process:
>> 1. Tag the dev tree
>> 2. merge the dev tree back into master
>> 3. Create 2.5.0 branch
>> 4. File issues from 2.5.0 in JIRA
>>
>> I also propose that we automate the tagging.  If an RC is broken, we
>> just cut another RC.  A lot of our retagging is done to get around the
>> pain of having to do another RC.  The biggest part of the delay is
>> waiting for every single platform maintainer to tag their platform
>> after the JS was tagged.  For example, I tagged rc2 for the JS and for
>> Android on Monday last week from my hotel room, and the release wasn't
>> fully tagged until this week.  I'm fine with RCs going up to 10 as
>> long as we can release early, release often and release when we want
>> to and not run out of time and have to delay.
>>
>> On Thu, Dec 20, 2012 at 10:33 AM, Brian LeRoux <b@brian.io> wrote:
>>> Truth. Though lets not get hung up on the past and just focus on the
>>> present. We've done a really good job getting where we are.
>>>
>>> So, Joe, are you saying you like the idea of three long lived branches
>>> and merges happen from local feature branches?
>>>
>>>
>>> On Thu, Dec 20, 2012 at 10:22 AM, Joe Bowser <bowserj@gmail.com> wrote:
>>>> We are totally doing something wrong with the way that we do releases.
>>>>  I personally think that we're not using git right, and here's why:
>>>>
>>>> Currently, when we do a release, we tag the RC, and we test the RC.
>>>> There's nothing preventing us from putting things after that tag and
>>>> if we don't want to those things in the release branching off that
>>>> tag.  We've done it before and other than the problem with CoHo, it
>>>> worked really well.  I propose that instead of tagging the release, we
>>>> branch when we want to do a release, and we do all the bug fixes on
>>>> that branch.  Once that branch is ready to roll, we merge it back into
>>>> master.  In fact, nobody should be working on master except to do
>>>> merges.  The way we're doing this now feels dirty and wrong.
>>>>
>>>> I honestly feel that this is a much faster way of working, and that
>>>> we're missing the point if we have to tell everyone to jump out of the
>>>> pool every time we do an RC.  I know that we could be working on our
>>>> branches, but that work is almost entirely invisible to the rest of
>>>> the project until it's time to merge it back in, which takes forever.
>>>>
>>>>
>>>> On Thu, Dec 20, 2012 at 10:07 AM, Michal Mocny <mmocny@chromium.org>
>>>>wrote:
>>>>> So there is something to be said about having devs shift focus from
>>>>>dev to
>>>>> testing during an RC.  However, as the team grows, not all of us are
>>>>>really
>>>>> being responsible for cutting releases.  Maybe that means we need to
>>>>>train
>>>>> the entire team to change current behavior, but that doesn't feel
>>>>> necessary/scalable.
>>>>>
>>>>> With growing external contributions, I would have to say that a code
>>>>>freeze
>>>>> on trunk doesn't seem to make as much sense.
>>>>>
>>>>> -Michal
>>>>>
>>>>>
>>>>> On Thu, Dec 20, 2012 at 9:47 AM, Andrew Grieve
>>>>><agrieve@chromium.org> wrote:
>>>>>
>>>>>> I definitely think we'd get more done if we didn't have such a long
>>>>>> code-freeze. I'm not sure this is the same as what you were
>>>>>>suggesting, but
>>>>>> have a script/tool to branch all of the platforms into an rc
>>>>>>branch. Then,
>>>>>> each platform can fix themselves up a bit and tag their RC.
>>>>>>Meanwhile, dev
>>>>>> can continue to happen on edge.
>>>>>>
>>>>>> My main concern with our current approach is just that the
>>>>>>code-freeze time
>>>>>> is super long.
>>>>>>
>>>>>>
>>>>>> On Wed, Dec 19, 2012 at 3:36 PM, Marcel Kinard <cmarcelk@gmail.com>
>>>>>>wrote:
>>>>>>
>>>>>> > One of the things that strikes me here is the difference between
>>>>>>calendar
>>>>>> > time and effort time. (This assumes folks already concurred
that
>>>>>>the rc
>>>>>> is
>>>>>> > ready to release.) Based on my reading of
>>>>>>http://wiki.apache.org/**
>>>>>> > cordova/CuttingReleases
>>>>>><http://wiki.apache.org/cordova/CuttingReleases>there
>>>>>> isn't a lot of effort time involved to cut a release. It seems like
>>>>>>a
>>>>>> > good chunk of the calendar time is getting folks to tag their
>>>>>>platform.
>>>>>> > Ideally the promotion from rc to final should take very little
>>>>>>effort
>>>>>> time.
>>>>>> >
>>>>>> > What I like about the rc is that it provides a settling mechanism
>>>>>>for the
>>>>>> > churn to calm down, run tests across more integration, and see
>>>>>>the bigger
>>>>>> > picture to assess release readiness. I would expect that the
>>>>>>promotion
>>>>>> from
>>>>>> > edge to rc should take a decent amount of effort time, but not
>>>>>>because of
>>>>>> > the "cut" activities.
>>>>>> >
>>>>>> > So when we are at rc and don't find any surprises, why does
it
>>>>>>take a
>>>>>> week
>>>>>> > to promote to final? If we spend a week in rc1, another week
in
>>>>>>rc2, and
>>>>>> > another week to cut final, that leaves only 1 week in a 4-week
>>>>>>cycle for
>>>>>> > active dev work?
>>>>>> >
>>>>>> > I like the ideal of a channel/stream/branch/whatever where there
>>>>>>is a
>>>>>> > place for the rc to settle without necessarily blocking commits
>>>>>>to edge.
>>>>>> > Where I'm going with this is that if there is an area where
>>>>>>commits to
>>>>>> the
>>>>>> > rc are carefully controlled, then perhaps one person (i.e, Steve
>>>>>>G) could
>>>>>> > cut the release for ALL platforms using scripts. This may involve
>>>>>>that
>>>>>> one
>>>>>> > person tagging/branching/whatever across multiple platforms.
>>>>>> >
>>>>>> > I also like putting the "how to cut" magic in each platform.
Then
>>>>>>perhaps
>>>>>> > a good chunk of coho is tests to make sure that the platform
magic
>>>>>> > delivered the correct format to it.
>>>>>> >
>>>>>> > -- Marcel Kinard
>>>>>> >
>>>>>>


Mime
View raw message