cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <mmo...@chromium.org>
Subject Re: too long to package a release?
Date Wed, 02 Jan 2013 21:51:34 GMT
Also: while I personally prefer master to be the dev channel, I will say
that I do like Gord's suggestion of how its done in ripple in that the name
of the dev branch is 'next' and not '2.3.0' so that your dev setup doesn't
need to change every month.

Gord: how do you deal with bugfixes/point releases?  Do you fix in feature
branch, merge into next, and then cherry-pick/merge just that fix into
master before doing a major release?  Or, do you just offer bugfixes via
'next'?


On Wed, Jan 2, 2013 at 4:45 PM, Michal Mocny <mmocny@chromium.org> wrote:

> I don't have much weight here, but personally I feel that this seems
> backwards.
>
> With this proposal (if I understand it), when you do a fresh checkout of
> the codebase, instead of sitting on the bleeding edge, you would be sitting
> at a "stable" release which is conceptually read-only for most contributors
> (writes happen in the form of batch "releases" which itself would just be
> some git-fu to rebase master).
>
> I am happy enough to have features be worked on in branches etc, I just
> think that it should be flipped and the stable release be the branch and
> dev to be on master.
>
>
> As a separate issue, I would suggest not using branches to "name" point
> releases, but just tag them.  If you have a 2.3.0 release, and you need to
> fix a bug in 2.3.1, those should not become two logically separate code
> branches with independent dev, but rather they are a logically single
> timeline with many names for each historically significant commit, right?
>  Thats what tags are for (http://git-scm.com/book/en/Git-Basics-Tagging).
>
> -Michal
>
>
> On Wed, Jan 2, 2013 at 3:05 PM, Gord Tanner <gtanner@gmail.com> wrote:
>
>> 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