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 22:11:41 GMT
Also a problem we have encountered with using a 'next' branch for active
development is from third party commits.

Every single 3rd party pull request is going to come into master.

You can ether:
1. tell them to redo it on next
2. rebase it into next for them and let them know for next time.

The cost of option 2 gets more the longer it takes to release.  A 3rd party
pull request coming in could be based on code that is 2+ months old.

This isn't a vote against a development branch, but a small annoyance we
have run into.


On Wed, Jan 2, 2013 at 5:08 PM, Gord Tanner <gtanner@gmail.com> wrote:

> A hot fix is usually branched off of master, tested, merged and released.
>
> We then rebase / merge the hotfix up into next.
>
>
> On Wed, Jan 2, 2013 at 4:51 PM, Michal Mocny <mmocny@chromium.org> wrote:
>
>> 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