cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gord Tanner <gtan...@gmail.com>
Subject Re: too long to package a release?
Date Wed, 02 Jan 2013 20:05:05 GMT
This is what we have done in ripple (and webworks)

master - always stable current shipping code
next - always 'stable' next release. Expectation that code has been tested
/ run before merged into this branch.
feature branches - branched off of next and merged into next when stable /
done. Not expected to be stable or runnable until merge time.



On Wed, Jan 2, 2013 at 2:32 PM, Filip Maj <fil@adobe.com> wrote:

> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message