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:32:38 GMT
Am I correct when I say that, with this approach, master becomes a series
of merge commits coming from dev, then ?

A couple questions to follow up:

- "features get forked from stable" - forked from master, yes?
- "features, when ready, tested against dev branch" - what does this mean?
Does this mean, you would merge feature branch into dev branch (locally)
then run tests to make sure things work?

On 1/2/13 11:19 AM, "Joe Bowser" <bowserj@gmail.com> wrote:

>OK, Let's rethink this:
>
>After talking with Brian on the 21st, I think we agree on this:
>
> * Master remains stable and sits at the most recent released code
>(i.e. 2.3.0 once we get 2.3.0 done) (Stable Channel)
> * Dev happens on branches for the releases (i.e. 2.4.0) (Dev Channel)
> * In the case of a point release, dev happens in the branch of the
>major release (i.e. 2.3.1 would happen in the 2.3.0 branch, not
>master) (Testing Channel)
> * Features get forked on stable then once the feature is ready,
>tested against the dev branch.  If they work with stable, they SHOULD
>work with 2.4.0.  If they don't, the tickets get added to 2.4.0 to
>make it work with that release.  That way things are more predictable
>as far as new features are concerned. (You will burn your face
>channel).
>
>Does that make sense? Working on master for things causes us pain and
>we should use git conventions to make it simpler for people who expect
>our master to work all the time.  I don't think this will speed up the
>release as much as automating tagging of RCs so that when the JS is
>tagged, everything else is tagged.  The week it takes to tag an RC is
>way too long.
>
>
>On Wed, Jan 2, 2013 at 11:08 AM, Filip Maj <fil@adobe.com> wrote:
>> 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