You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Filip Maj <fi...@adobe.com> on 2013/01/02 20:08:10 UTC
Re: too long to package a release?
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 <bo...@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 <bo...@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 <mm...@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
>>>>><ag...@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 <cm...@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
>>>>>> >
>>>>>>
Re: too long to package a release?
Posted by Filip Maj <fi...@adobe.com>.
Thanks Joe, that makes sense to me. I support this endeavor.
On 1/2/13 11:36 AM, "Joe Bowser" <bo...@gmail.com> wrote:
>On Wed, Jan 2, 2013 at 11:32 AM, Filip Maj <fi...@adobe.com> wrote:
>> Am I correct when I say that, with this approach, master becomes a
>>series
>> of merge commits coming from dev, then ?
>>
>That's correct!
>
>> A couple questions to follow up:
>>
>> - "features get forked from stable" - forked from master, yes?
>
>Yes! Feature branches start off master, not off the dev branch because
>it's not stable and can change.
>
>> - "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?
>>
>
>Yes! That way if things don't work, we know it's within the past month
>where we were changing things and have a much better shot of fixing
>them than if we're doing dev on master. It's a nice process tool to
>have when you're working on a feature that takes multiple months to
>find where your feature breaks instead of hunting through a git
>history or spending hours blindly debugging. I know that I've gone on
>way too many fishing expeditions in our source.
Re: too long to package a release?
Posted by Joe Bowser <bo...@gmail.com>.
On Wed, Jan 2, 2013 at 11:32 AM, Filip Maj <fi...@adobe.com> wrote:
> Am I correct when I say that, with this approach, master becomes a series
> of merge commits coming from dev, then ?
>
That's correct!
> A couple questions to follow up:
>
> - "features get forked from stable" - forked from master, yes?
Yes! Feature branches start off master, not off the dev branch because
it's not stable and can change.
> - "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?
>
Yes! That way if things don't work, we know it's within the past month
where we were changing things and have a much better shot of fixing
them than if we're doing dev on master. It's a nice process tool to
have when you're working on a feature that takes multiple months to
find where your feature breaks instead of hunting through a git
history or spending hours blindly debugging. I know that I've gone on
way too many fishing expeditions in our source.
Re: too long to package a release?
Posted by Joe Bowser <bo...@gmail.com>.
On Wed, Jan 2, 2013 at 1:45 PM, Michal Mocny <mm...@chromium.org> wrote:
>
> 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).
If we do dev in master, we run into a situation where master has stuff
that we're not comfortable springing on someone for a point release.
For example, when we did CordovaWebView, we committed that in 1.9, but
we needed to do a 1.8.1. Introducing CordovaWebView was already bad
enough in a major release but doing that in a point release would have
been completely ridiculous and our users would be asking for all our
heads instead of just mine! Therefore, we created a 1.8.x branch and
did 1.8.1 on that branch instead of the master.
I think point releases should exist in the major releases branch.
That way 1.8.0 will have tags for 1.8.0, 1.8.1 and so forth.
Furthermore, it may not make sense to merge this back to master for
certain cases, because the code may not exist in the next release.
Re: too long to package a release?
Posted by Andrew Grieve <ag...@chromium.org>.
I think cherry-picking the same as a rebase+merge?
If branches are:
feature --> dev --> unstable --> stable
Then I don't think we'd ever do dev->stable.
Who should do it? I think for dev-> unstable, whoever wants to start a
release can just do it (maybe we could rotate the responsibility of release
person?)
For unstable->stable, I think owners from each platform should do this (in
the same spirit as is done right now), since this is essentially the same
as the tagging step.
When should we do it? For dev->unstable, maybe 2 weeks before our planned
release date? This gives 2 weeks of testing / release candidates before
tagging a final.
Should RCs be tagged on unstable or stable?
I think both "Next" or "Staging" make more sense than "unstable".
On Mon, Jan 14, 2013 at 6:10 PM, Brian LeRoux <b...@brian.io> wrote:
> Oh, yes, that is true. I was assuming (naively) that this wouldn't be
> a likely case if we were diligent about rebasing before commits
> landing.
>
> So, the real trick here is, a workflow of:
>
> feature --> dev --> unstable --> stable
>
> When, and more importantly who, does the Canonical brach to Canonical
> branch merges? (Eg. dev --> stable )
>
>
>
> On Mon, Jan 14, 2013 at 2:48 PM, Braden Shepherdson <br...@chromium.org>
> wrote:
> > Aside from the extra overhead and coordination, which I think are a major
> > problem, this is a recipe for disaster with merge commits. This doesn't
> > require manual conflict resolution to be a problem. Just that, if feature
> > branches A and B are merged into dev/unstable and a merge commit is
> > created, they and their merge commit now have to be moved to
> unstable/next
> > as a group. These features may be from different developers, etc. etc.
> >
> >
> > On Mon, Jan 14, 2013 at 5:34 PM, Brian LeRoux <b...@brian.io> wrote:
> >
> >> I think its basically the same except cherry picking not necessary.
> >> (But I've been known to be very wrong so take that with a grain of
> >> salt!)
> >>
> >> You work on a Feature branch. It gets rolled into Dev as needed so
> >> others can merge / collaborate on said feature. When it feels right
> >> instead of merging a large set of potentially breaking commits to
> >> Unstable the dev working on said feature just merges that feature.
> >> This would require more responsibility for the committer to keep track
> >> of their feature branches which I could see as being more overhead.
> >>
> >> My ideal here is to get to a point where there is something, whatever
> >> it is, that we want to denote as a release. That something should not
> >> require a whole bunch of coordination. There should be a working
> >> branch, whatever we call it, ready for a tag and nothing else on any
> >> arbitrary date to be considered a release. Does that make sense?
> >>
> >>
> >>
> >> On Mon, Jan 14, 2013 at 2:18 PM, Andrew Grieve <ag...@chromium.org>
> >> wrote:
> >> > Could you elaborate on what the workflow would be if we merged only
> from
> >> > Feature branches?
> >> >
> >> > On Mon, Jan 14, 2013 at 5:14 PM, Brian LeRoux <b...@brian.io> wrote:
> >> >
> >> >> So, what if Canonical branches only received merges from Feature
> >> >> branches...?
> >> >>
> >> >> On Mon, Jan 14, 2013 at 2:02 PM, Andrew Grieve <agrieve@chromium.org
> >
> >> >> wrote:
> >> >> > On Mon, Jan 14, 2013 at 4:54 PM, Filip Maj <fi...@adobe.com> wrote:
> >> >> >
> >> >> >>
> >> >> >> >But do Canonical branches merge into each other? I'm thinking no.
> >> >> >>
> >> >> >> My understanding:
> >> >> >>
> >> >> >> - work goes into feature branches
> >> >> >> - when contributor(s) deem feature is ready, merge into Unstable,
> >> which
> >> >> >> then gets vetted (test!!!!!)
> >> >> >> - at some point unstable merges into Next
> >> >> >> - when tagging, we merge Next into Stable and tag
> >> >> >>
> >> >> >
> >> >> > That's my understanding as well.
> >> >> >
> >> >> > The "At some point" part would be when we say "hey, let's start
> >> working
> >> >> on
> >> >> > cutting a release", which should align with the wiki's
> >> >> > RoadMap<http://wiki.apache.org/cordova/RoadmapProjects> (which
> >> >> > targeted 2.3 for November, whoops!).
> >> >> >
> >> >> >
> >> >> >>
> >> >> >> Would be different for bug fixes or other maintenance-type commits
> >> too,
> >> >> >> ya? Those would be directly into Next.
> >> >> >>
> >> >> > It might cause headaches to commit bug-fixes into Next when it
> comes
> >> time
> >> >> > to merge Unstable -> Next.
> >> >> >
> >> >> >
> >> >> >>
> >> >> >> Finally, what about hot fixes / patch releases? Branch off the
> tag in
> >> >> >> Stable and put hot patch work into there?
> >> >> >>
> >> >> > Agree. I think the flow here should be to commit change to Unstable
> >> and
> >> >> > then cherry-pick it into a branch off the tag (when feasible).
> >> >>
> >>
>
Re: too long to package a release?
Posted by Brian LeRoux <b...@brian.io>.
Oh, yes, that is true. I was assuming (naively) that this wouldn't be
a likely case if we were diligent about rebasing before commits
landing.
So, the real trick here is, a workflow of:
feature --> dev --> unstable --> stable
When, and more importantly who, does the Canonical brach to Canonical
branch merges? (Eg. dev --> stable )
On Mon, Jan 14, 2013 at 2:48 PM, Braden Shepherdson <br...@chromium.org> wrote:
> Aside from the extra overhead and coordination, which I think are a major
> problem, this is a recipe for disaster with merge commits. This doesn't
> require manual conflict resolution to be a problem. Just that, if feature
> branches A and B are merged into dev/unstable and a merge commit is
> created, they and their merge commit now have to be moved to unstable/next
> as a group. These features may be from different developers, etc. etc.
>
>
> On Mon, Jan 14, 2013 at 5:34 PM, Brian LeRoux <b...@brian.io> wrote:
>
>> I think its basically the same except cherry picking not necessary.
>> (But I've been known to be very wrong so take that with a grain of
>> salt!)
>>
>> You work on a Feature branch. It gets rolled into Dev as needed so
>> others can merge / collaborate on said feature. When it feels right
>> instead of merging a large set of potentially breaking commits to
>> Unstable the dev working on said feature just merges that feature.
>> This would require more responsibility for the committer to keep track
>> of their feature branches which I could see as being more overhead.
>>
>> My ideal here is to get to a point where there is something, whatever
>> it is, that we want to denote as a release. That something should not
>> require a whole bunch of coordination. There should be a working
>> branch, whatever we call it, ready for a tag and nothing else on any
>> arbitrary date to be considered a release. Does that make sense?
>>
>>
>>
>> On Mon, Jan 14, 2013 at 2:18 PM, Andrew Grieve <ag...@chromium.org>
>> wrote:
>> > Could you elaborate on what the workflow would be if we merged only from
>> > Feature branches?
>> >
>> > On Mon, Jan 14, 2013 at 5:14 PM, Brian LeRoux <b...@brian.io> wrote:
>> >
>> >> So, what if Canonical branches only received merges from Feature
>> >> branches...?
>> >>
>> >> On Mon, Jan 14, 2013 at 2:02 PM, Andrew Grieve <ag...@chromium.org>
>> >> wrote:
>> >> > On Mon, Jan 14, 2013 at 4:54 PM, Filip Maj <fi...@adobe.com> wrote:
>> >> >
>> >> >>
>> >> >> >But do Canonical branches merge into each other? I'm thinking no.
>> >> >>
>> >> >> My understanding:
>> >> >>
>> >> >> - work goes into feature branches
>> >> >> - when contributor(s) deem feature is ready, merge into Unstable,
>> which
>> >> >> then gets vetted (test!!!!!)
>> >> >> - at some point unstable merges into Next
>> >> >> - when tagging, we merge Next into Stable and tag
>> >> >>
>> >> >
>> >> > That's my understanding as well.
>> >> >
>> >> > The "At some point" part would be when we say "hey, let's start
>> working
>> >> on
>> >> > cutting a release", which should align with the wiki's
>> >> > RoadMap<http://wiki.apache.org/cordova/RoadmapProjects> (which
>> >> > targeted 2.3 for November, whoops!).
>> >> >
>> >> >
>> >> >>
>> >> >> Would be different for bug fixes or other maintenance-type commits
>> too,
>> >> >> ya? Those would be directly into Next.
>> >> >>
>> >> > It might cause headaches to commit bug-fixes into Next when it comes
>> time
>> >> > to merge Unstable -> Next.
>> >> >
>> >> >
>> >> >>
>> >> >> Finally, what about hot fixes / patch releases? Branch off the tag in
>> >> >> Stable and put hot patch work into there?
>> >> >>
>> >> > Agree. I think the flow here should be to commit change to Unstable
>> and
>> >> > then cherry-pick it into a branch off the tag (when feasible).
>> >>
>>
Re: too long to package a release?
Posted by Braden Shepherdson <br...@chromium.org>.
Aside from the extra overhead and coordination, which I think are a major
problem, this is a recipe for disaster with merge commits. This doesn't
require manual conflict resolution to be a problem. Just that, if feature
branches A and B are merged into dev/unstable and a merge commit is
created, they and their merge commit now have to be moved to unstable/next
as a group. These features may be from different developers, etc. etc.
On Mon, Jan 14, 2013 at 5:34 PM, Brian LeRoux <b...@brian.io> wrote:
> I think its basically the same except cherry picking not necessary.
> (But I've been known to be very wrong so take that with a grain of
> salt!)
>
> You work on a Feature branch. It gets rolled into Dev as needed so
> others can merge / collaborate on said feature. When it feels right
> instead of merging a large set of potentially breaking commits to
> Unstable the dev working on said feature just merges that feature.
> This would require more responsibility for the committer to keep track
> of their feature branches which I could see as being more overhead.
>
> My ideal here is to get to a point where there is something, whatever
> it is, that we want to denote as a release. That something should not
> require a whole bunch of coordination. There should be a working
> branch, whatever we call it, ready for a tag and nothing else on any
> arbitrary date to be considered a release. Does that make sense?
>
>
>
> On Mon, Jan 14, 2013 at 2:18 PM, Andrew Grieve <ag...@chromium.org>
> wrote:
> > Could you elaborate on what the workflow would be if we merged only from
> > Feature branches?
> >
> > On Mon, Jan 14, 2013 at 5:14 PM, Brian LeRoux <b...@brian.io> wrote:
> >
> >> So, what if Canonical branches only received merges from Feature
> >> branches...?
> >>
> >> On Mon, Jan 14, 2013 at 2:02 PM, Andrew Grieve <ag...@chromium.org>
> >> wrote:
> >> > On Mon, Jan 14, 2013 at 4:54 PM, Filip Maj <fi...@adobe.com> wrote:
> >> >
> >> >>
> >> >> >But do Canonical branches merge into each other? I'm thinking no.
> >> >>
> >> >> My understanding:
> >> >>
> >> >> - work goes into feature branches
> >> >> - when contributor(s) deem feature is ready, merge into Unstable,
> which
> >> >> then gets vetted (test!!!!!)
> >> >> - at some point unstable merges into Next
> >> >> - when tagging, we merge Next into Stable and tag
> >> >>
> >> >
> >> > That's my understanding as well.
> >> >
> >> > The "At some point" part would be when we say "hey, let's start
> working
> >> on
> >> > cutting a release", which should align with the wiki's
> >> > RoadMap<http://wiki.apache.org/cordova/RoadmapProjects> (which
> >> > targeted 2.3 for November, whoops!).
> >> >
> >> >
> >> >>
> >> >> Would be different for bug fixes or other maintenance-type commits
> too,
> >> >> ya? Those would be directly into Next.
> >> >>
> >> > It might cause headaches to commit bug-fixes into Next when it comes
> time
> >> > to merge Unstable -> Next.
> >> >
> >> >
> >> >>
> >> >> Finally, what about hot fixes / patch releases? Branch off the tag in
> >> >> Stable and put hot patch work into there?
> >> >>
> >> > Agree. I think the flow here should be to commit change to Unstable
> and
> >> > then cherry-pick it into a branch off the tag (when feasible).
> >>
>
Re: too long to package a release?
Posted by Brian LeRoux <b...@brian.io>.
Mike: open tickets against the platforms for this. I think its a great idea.
On Mon, Jan 14, 2013 at 2:47 PM, Michael Brooks
<mi...@michaelbrooks.ca> wrote:
>>
>> My ideal here is to get to a point where there is something, whatever
>> it is, that we want to denote as a release. That something should not
>> require a whole bunch of coordination. There should be a working
>> branch, whatever we call it, ready for a tag and nothing else on any
>> arbitrary date to be considered a release. Does that make sense?
>
>
> Now's my chance to loop back to the other discussion point of this thread.
> Building a release should be automated and I'd like to propose that we
> introduce another script:
>
> ./bin/dist <version>
>
> I would go as far as I require any platform wanting to be included in a
> release
> to include the distribution script. For what it's worth, BlackBerry has had
> this
> script for over two years.
>
> Ideally, we should also standardize how to install any dev environment
> dependencies. In my mind, it would make sense to require a script similar to
> the UNIX ./configure to install and/or verify any developer dependencies.
>
> To do an Apache Cordova release, we following steps similar to:
>
> Each platform
> Checkout stable git branch
> $ ./configure
> $ ./bin/dist <version>
> Zip everything up
>
> On Mon, Jan 14, 2013 at 2:34 PM, Brian LeRoux <b...@brian.io> wrote:
>
>> I think its basically the same except cherry picking not necessary.
>> (But I've been known to be very wrong so take that with a grain of
>> salt!)
>>
>> You work on a Feature branch. It gets rolled into Dev as needed so
>> others can merge / collaborate on said feature. When it feels right
>> instead of merging a large set of potentially breaking commits to
>> Unstable the dev working on said feature just merges that feature.
>> This would require more responsibility for the committer to keep track
>> of their feature branches which I could see as being more overhead.
>>
>> My ideal here is to get to a point where there is something, whatever
>> it is, that we want to denote as a release. That something should not
>> require a whole bunch of coordination. There should be a working
>> branch, whatever we call it, ready for a tag and nothing else on any
>> arbitrary date to be considered a release. Does that make sense?
>>
>>
>>
>> On Mon, Jan 14, 2013 at 2:18 PM, Andrew Grieve <ag...@chromium.org>
>> wrote:
>> > Could you elaborate on what the workflow would be if we merged only from
>> > Feature branches?
>> >
>> > On Mon, Jan 14, 2013 at 5:14 PM, Brian LeRoux <b...@brian.io> wrote:
>> >
>> >> So, what if Canonical branches only received merges from Feature
>> >> branches...?
>> >>
>> >> On Mon, Jan 14, 2013 at 2:02 PM, Andrew Grieve <ag...@chromium.org>
>> >> wrote:
>> >> > On Mon, Jan 14, 2013 at 4:54 PM, Filip Maj <fi...@adobe.com> wrote:
>> >> >
>> >> >>
>> >> >> >But do Canonical branches merge into each other? I'm thinking no.
>> >> >>
>> >> >> My understanding:
>> >> >>
>> >> >> - work goes into feature branches
>> >> >> - when contributor(s) deem feature is ready, merge into Unstable,
>> which
>> >> >> then gets vetted (test!!!!!)
>> >> >> - at some point unstable merges into Next
>> >> >> - when tagging, we merge Next into Stable and tag
>> >> >>
>> >> >
>> >> > That's my understanding as well.
>> >> >
>> >> > The "At some point" part would be when we say "hey, let's start
>> working
>> >> on
>> >> > cutting a release", which should align with the wiki's
>> >> > RoadMap<http://wiki.apache.org/cordova/RoadmapProjects> (which
>> >> > targeted 2.3 for November, whoops!).
>> >> >
>> >> >
>> >> >>
>> >> >> Would be different for bug fixes or other maintenance-type commits
>> too,
>> >> >> ya? Those would be directly into Next.
>> >> >>
>> >> > It might cause headaches to commit bug-fixes into Next when it comes
>> time
>> >> > to merge Unstable -> Next.
>> >> >
>> >> >
>> >> >>
>> >> >> Finally, what about hot fixes / patch releases? Branch off the tag in
>> >> >> Stable and put hot patch work into there?
>> >> >>
>> >> > Agree. I think the flow here should be to commit change to Unstable
>> and
>> >> > then cherry-pick it into a branch off the tag (when feasible).
>> >>
>>
Re: too long to package a release?
Posted by Michael Brooks <mi...@michaelbrooks.ca>.
>
> My ideal here is to get to a point where there is something, whatever
> it is, that we want to denote as a release. That something should not
> require a whole bunch of coordination. There should be a working
> branch, whatever we call it, ready for a tag and nothing else on any
> arbitrary date to be considered a release. Does that make sense?
Now's my chance to loop back to the other discussion point of this thread.
Building a release should be automated and I'd like to propose that we
introduce another script:
./bin/dist <version>
I would go as far as I require any platform wanting to be included in a
release
to include the distribution script. For what it's worth, BlackBerry has had
this
script for over two years.
Ideally, we should also standardize how to install any dev environment
dependencies. In my mind, it would make sense to require a script similar to
the UNIX ./configure to install and/or verify any developer dependencies.
To do an Apache Cordova release, we following steps similar to:
Each platform
Checkout stable git branch
$ ./configure
$ ./bin/dist <version>
Zip everything up
On Mon, Jan 14, 2013 at 2:34 PM, Brian LeRoux <b...@brian.io> wrote:
> I think its basically the same except cherry picking not necessary.
> (But I've been known to be very wrong so take that with a grain of
> salt!)
>
> You work on a Feature branch. It gets rolled into Dev as needed so
> others can merge / collaborate on said feature. When it feels right
> instead of merging a large set of potentially breaking commits to
> Unstable the dev working on said feature just merges that feature.
> This would require more responsibility for the committer to keep track
> of their feature branches which I could see as being more overhead.
>
> My ideal here is to get to a point where there is something, whatever
> it is, that we want to denote as a release. That something should not
> require a whole bunch of coordination. There should be a working
> branch, whatever we call it, ready for a tag and nothing else on any
> arbitrary date to be considered a release. Does that make sense?
>
>
>
> On Mon, Jan 14, 2013 at 2:18 PM, Andrew Grieve <ag...@chromium.org>
> wrote:
> > Could you elaborate on what the workflow would be if we merged only from
> > Feature branches?
> >
> > On Mon, Jan 14, 2013 at 5:14 PM, Brian LeRoux <b...@brian.io> wrote:
> >
> >> So, what if Canonical branches only received merges from Feature
> >> branches...?
> >>
> >> On Mon, Jan 14, 2013 at 2:02 PM, Andrew Grieve <ag...@chromium.org>
> >> wrote:
> >> > On Mon, Jan 14, 2013 at 4:54 PM, Filip Maj <fi...@adobe.com> wrote:
> >> >
> >> >>
> >> >> >But do Canonical branches merge into each other? I'm thinking no.
> >> >>
> >> >> My understanding:
> >> >>
> >> >> - work goes into feature branches
> >> >> - when contributor(s) deem feature is ready, merge into Unstable,
> which
> >> >> then gets vetted (test!!!!!)
> >> >> - at some point unstable merges into Next
> >> >> - when tagging, we merge Next into Stable and tag
> >> >>
> >> >
> >> > That's my understanding as well.
> >> >
> >> > The "At some point" part would be when we say "hey, let's start
> working
> >> on
> >> > cutting a release", which should align with the wiki's
> >> > RoadMap<http://wiki.apache.org/cordova/RoadmapProjects> (which
> >> > targeted 2.3 for November, whoops!).
> >> >
> >> >
> >> >>
> >> >> Would be different for bug fixes or other maintenance-type commits
> too,
> >> >> ya? Those would be directly into Next.
> >> >>
> >> > It might cause headaches to commit bug-fixes into Next when it comes
> time
> >> > to merge Unstable -> Next.
> >> >
> >> >
> >> >>
> >> >> Finally, what about hot fixes / patch releases? Branch off the tag in
> >> >> Stable and put hot patch work into there?
> >> >>
> >> > Agree. I think the flow here should be to commit change to Unstable
> and
> >> > then cherry-pick it into a branch off the tag (when feasible).
> >>
>
Re: too long to package a release?
Posted by Becky Gibson <gi...@gmail.com>.
I, too, have been silent as I don't have a strong opinion and I don't have
a better solution to offer. But, I do have to agree with Jesse that the
solution seems overly complicated. I am not a git guru nor do I want to
be. I can see easily making mistakes cherry picking and merging into
specific branches. I understand the problem of having to delay commits
while we are prepping a release but I'm not sure all of the extra process
is going to ease the pain enough to make it worthwhile. Maybe I just need
some extra git hand holding but I'd hate to have to go search google for
git help every time I want to make a commit!
But, like I said, I don't have a better solution so take my comments with a
grain of salt (and perhaps some tequila).
-b
On Thu, Jan 24, 2013 at 2:09 PM, Braden Shepherdson <br...@chromium.org>wrote:
> The founding goal we're trying to accomplish here is that we don't want
> everyone sitting on changes to be in the next version while we use master
> to prep a release.
>
> I don't think having one branch for prepping the release and another for
> main development is a lot of bureaucracy.
>
>
> On Thu, Jan 24, 2013 at 1:57 PM, Jesse MacFadyen <purplecabbage@gmail.com
> >wrote:
>
> > I have been quietly listening on this thread, but thought I should at
> > least share my opinion.
> >
> > I don't think adding contribution rules helps anyone. Git is
> > complicated enough as it is, and this just all seems like bureaucracy.
> >
> > I think master should always contain the latest stable code, and be
> > periodically tagged with rc's and versions.
> > All work should be done in personal forks and feature branches.
> > If the latest tag of master is an rc, then we should only be merging
> > bugfixes, until the release.
> > Immediately after tagging a version we decide which feature branches
> > and pull requests to pull in, and go for it.
> >
> > I don't think this is much different from what we have, but I think
> > that is good.
> > The suggestions thus far, while interesting, don't increase our
> > velocity in my opinion. Also, I can also pretty much guaranty I'll
> > screw it up for the next 3-4 versions. ( because I'm dumb )
> >
> > Cheers,
> > Jesse
> >
> >
> >
> > On 2013-01-24, at 5:53 AM, Andrew Grieve <ag...@chromium.org> wrote:
> >
> > On Wed, Jan 23, 2013 at 4:58 PM, Michael Brooks <
> michael@michaelbrooks.ca
> > >wrote:
> >
> > > Before we move forward, I have a few questions about the "no master"
> > > approach.
> > >
> > > There is *no* master branch, so that community-driven pull requests
> will
> > be
> > >> forced to think about which branch to request against.
> > >
> > >
> > > - Andrew, can you cite other projects that do not use a master branch?
> > This project is my first time using git / github, so I don't have much to
> > draw from. I was going off of others' suggestions on this thread when I
> > proposed the names.
> >
> >
> > > - On Github, you must have a default branch. If not master, it must be
> > > something else. So, users are not forced to think about the branch to
> > send
> > > a pull request again... they will likely just use the default.
> >
> > Hmm, good point. The goal is to get people downloading Cordova for use to
> > end up with Stable, and for developers to send pull requests against dev.
> > With a forced default branch, I don't think we can accomplish this.
> >
> >
> > >
> > > - Why is the "stable" branch not just "master"?
> >
> > My thinking was that it's not obvious whether Master == bleeding edge, or
> > Master == Stable version. Using the names "dev" and "stable" makes it a
> bit
> > clear.
> >
> >
> >
> > So... If github forces us to have a default branch, I'm thinking that
> > having users send pull requests against "dev" is more valuable than
> having
> > people download the latest "stable" by default. If people are pulling
> code
> > from github rather than from our release .zip files, then it's likely
> they
> > want to hack on it anyways, or that they want the dev version to see if
> > bugs are fixed.
> >
> > Soo.... Here's version #3! If anyone can think of how to keep the three
> > branches while addressing being forced to have a default branch, feel
> free
> > to speak up! :)
> >
> >
> > Cordova repositories have two main branches:
> > 1. master
> > 2. next
> >
> > Topic branches exist for collaborating on features, or for code-review
> > purposes.
> >
> > Cordova uses tags to label releases.
> > - Each release candidate has a tag. e.g. "2.2.0rc1"
> > - Each release has a tag. e.g. "2.2.0"
> > - The "latest" tag points to the last stable release (this follows npm
> > conventions)
> >
> >
> > 1. The "next" branch.
> > - This branch is used only when in the process of doing a release.
> > - All tags are created from this branch.
> > - All release-candidate bug-fixes are done on this branch.
> >
> > 2. The "master" branch.
> > - When not in the release-process, all commits are made here
> > - When in the release-process, all non-bugfix commits are made here
> > - This is where topic-branches are merged into.
> >
> > Cutting a release:
> > 1. git checkout next && git merge --ff-only master
> > 2. Test test test!
> > 3. Fix bugs by committing them directly to "next" and then doing a non-ff
> > merge of next into master
> > 4. Tag release candidate
> > 5. Repeat steps 2-4 as necessary
> > 6. Tag the release (both by version and by updating the "latest" tag)
> > 7. Create distribution .zip file
> > 8. Test one last time using the dist files
> >
> >
> >
> >
> >
> >
> >
> > >
> > > Thanks,
> > > Michael
> > >
> > > On Wed, Jan 23, 2013 at 11:25 AM, Brian LeRoux <b...@brian.io> wrote:
> > >
> > >> I'm liking it. Start in 2.5?
> > >>
> > >> On Wed, Jan 23, 2013 at 1:19 PM, Filip Maj <fi...@adobe.com> wrote:
> > >>> Looks great Andrew!
> > >>>
> > >>> If everyone's on board, how are we going to test run this? Flip a
> > > switch
> > >>> at a certain point, give it a shot with one repo for one RC?
> > >>>
> > >>> On 1/22/13 12:29 PM, "Andrew Grieve" <ag...@chromium.org> wrote:
> > >>>
> > >>>> Braden, you're right. I've now done some local playing around in
> git,
> > > and
> > >>>> have an updated proposal that uses merges instead of deleting
> > branches.
> > >>>> PTAL:
> > >>>>
> > >>>> Cordova repositories have three main branches:
> > >>>> 1. stable
> > >>>> 2. next
> > >>>> 3. dev
> > >>>>
> > >>>> Topic branches also exist for collaborating on features, or for
> > >>>> code-review
> > >>>> purposes.
> > >>>>
> > >>>> There is *no* master branch, so that community-driven pull requests
> > > will
> > >>>> be
> > >>>> forced to think about which branch to request against.
> > >>>>
> > >>>> 1. The "stable" branch.
> > >>>> - Sits at the latest stable release of cordova
> > >>>> - This changes only when doing fast-forward merges from "next"
> > >>>>
> > >>>> 2. The "next" branch.
> > >>>> - This branch is used only when in the process of doing a release.
> > >>>> - All tags (both stable and RC) are done on this branch.
> > >>>> - All release-candidate bug-fixes are done on this branch.
> > >>>>
> > >>>> 3. The "dev" branch.
> > >>>> - This is where non-release-candidate commits are done
> > >>>> - This is where topic-branches are merged into.
> > >>>>
> > >>>> Cutting a release:
> > >>>> 1. git checkout next && git merge --ff-only dev
> > >>>> 2. Test test test!
> > >>>> 3. Fix bugs by committing them directly to "next" and then doing a
> > > non-ff
> > >>>> merge of next into dev
> > >>>> 4. Tag release candidate
> > >>>> 5. Repeat steps 2-4 as necessary
> > >>>> 6. Tag the release
> > >>>> 7. Create distribution .zip file
> > >>>> 8. Test one last time using the dist files
> > >>>> 9. git checkout stable && git merge --ff-only next
> > >>>>
> > >>>>
> > >>>>
> > >>>> On Tue, Jan 22, 2013 at 1:59 PM, Braden Shepherdson
> > >>>> <br...@chromium.org>wrote:
> > >>>>
> > >>>>> I think deleting and recreating branches with the same name can
> cause
> > >>>>> badness in git[1] because of remotes. It's not really the same
> branch
> > >> in
> > >>>>> terms of commits, and git thinks that your old stable and the new
> > >> stable
> > >>>>> differ by all of each of their commits. Tags can be moved
> > > arbitrarily,
> > >>>>> so I
> > >>>>> think stable makes sense as a tag. I'm not sure about how best to
> > >> handle
> > >>>>> next.
> > >>>>>
> > >>>>> [1]
> > >
> >
> http://stackoverflow.com/questions/11844581/git-delete-and-recreate-branc
> > >>>>> h
> > >>>>>
> > >>>>>
> > >>>>> On Tue, Jan 22, 2013 at 11:31 AM, Andrew Grieve <
> > > agrieve@chromium.org
> > >>>>>> wrote:
> > >>>>>
> > >>>>>> Michal's attending hackathons for the week, and I'm not sure we
> > > need
> > >>>>> to
> > >>>>> do
> > >>>>>> a hang-out for this, as I think we really are quite close to
> > >> resolving
> > >>>>>> this. I'd really like to resolve this ASAP so that we don't need
> to
> > >>>>> have
> > >>>>> a
> > >>>>>> code-freeze for this release.
> > >>>>>>
> > >>>>>> Here's a proposal:
> > >>>>>>
> > >>>>>> Cordova repositories have three main branches:
> > >>>>>> 1. stable
> > >>>>>> 2. next
> > >>>>>> 3. dev
> > >>>>>>
> > >>>>>> Topic branches also exist for collaborating on features, or for
> > >>>>> code-review
> > >>>>>> purposes.
> > >>>>>>
> > >>>>>> There is *no* master branch, so that community-driven pull
> requests
> > >>>>> will
> > >>>>> be
> > >>>>>> forced to think about which branch to request against.
> > >>>>>>
> > >>>>>> 1. The "stable" branch.
> > >>>>>> - Sits at the latest stable release of cordova
> > >>>>>> - No one ever commits to the "stable" branch. It exists only as a
> > >>>>>> short-cut for checking out the latest stable tag.
> > >>>>>>
> > >>>>>> 2. The "next" branch.
> > >>>>>> - This branch exists only when in the process of doing a release.
> > >>>>>> - All tags (both stable and RC) are done on this branch.
> > >>>>>> - When a stable tag is done:
> > >>>>>> - The existing "stable" branch is deleted
> > >>>>>> - A new "stable" branch is created from "next".
> > >>>>>> - The "next" branch is deleted.
> > >>>>>>
> > >>>>>> 3. The "dev" branch.
> > >>>>>> - This is where all commits are done
> > >>>>>> - This is where topic-branches are merged into.
> > >>>>>>
> > >>>>>> Cutting a release:
> > >>>>>> 1. Create "next" from the HEAD of "dev"
> > >>>>>> 2. Test test test!
> > >>>>>> 3. Fix bugs by committing them to "dev" and then cherry-picking
> > > them
> > >>>>> into
> > >>>>>> "next"
> > >>>>>> 4. Tag release candidate
> > >>>>>> 5. Repeat steps 2-4 as necessary
> > >>>>>> 6. Tag the release
> > >>>>>> 7. Create distribution .zip file
> > >>>>>> 8. Test one last time using the dist files
> > >>>>>> 9. Delete "stable"
> > >>>>>> 10. Create a new "stable" by branching from the HEAD of "next"
> > >>>>>> 11. Delete the "next" branch
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> On Wed, Jan 16, 2013 at 10:34 AM, Michal Mocny <
> > > mmocny@chromium.org>
> > >>>>>> wrote:
> > >>>>>>
> > >>>>>>> Just going to throw out one of my personal requirements for
> > >> whatever
> > >>>>>>> proposal we come up with, so it doesn't get lost:
> > >>>>>>>
> > >>>>>>> * Feature branches are great for feature work and/or large
> > > sweeping
> > >>>>>>> changes, as are JIRA bugs for tracking them, but cordova has many
> > >>>>> many
> > >>>>>>> trivial issues that could be fixed with "drive-by" patches that
> > >>>>> require
> > >>>>>> as
> > >>>>>>> little friction to commit as possible.
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> On Tue, Jan 15, 2013 at 3:05 PM, Marcel Kinard <
> > > cmarcelk@gmail.com
> > >>>
> > >>>>>> wrote:
> > >>>>>>>
> > >>>>>>>> How about if there is a specific straw man proposal at the
> > >>>>> beginning
> > >>>>> of
> > >>>>>>>> the face-time? Then the folks that are in agreement won't need
> > > to
> > >>>>> say
> > >>>>>>>> anything ;-)
> > >>>>>>>>
> > >>>>>>>> Seriously, making adjustments to something tangible is easier
> > >> than
> > >>>>>>>> instantiating it from scratch. A volunteer for a very simple
> > >>>>> writeup
> > >>>>> on
> > >>>>>>> the
> > >>>>>>>> wiki?
> > >>>>>>>>
> > >>>>>>>> -- Marcel Kinard
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> On 1/14/2013 10:06 PM, Michal Mocny wrote:
> > >>>>>>>>
> > >>>>>>>>> Okay gentlemen, I think there have been countless good points
> > >>>>> made
> > >>>>>> from
> > >>>>>>>>> all
> > >>>>>>>>> parties, but also some bike-shedding.
> > >>>>>>>>>
> > >>>>>>>>> Perhaps it is time to schedule some face-time to better
> > >>>>> articulate
> > >>>>>> some
> > >>>>>>> of
> > >>>>>>>>> the finer points, and to help come to some consensus?
> > >>>>>>>>>
> > >>>>>>>>> -Michal
> > >
> >
>
Re: too long to package a release?
Posted by Filip Maj <fi...@adobe.com>.
Awesome! Stoked to see "next" branches dropping for the upcoming 2.5.0rc's
!
On 2/7/13 11:59 AM, "Andrew Grieve" <ag...@chromium.org> wrote:
>The doc's not up-to-date, but I think we ended on consensus for the code
>version. I've taken a stab at updating the wiki pages:
>
>http://wiki.apache.org/cordova/CordovaAndGit -- Added the idea of having
>both a master and a next branch
>http://wiki.apache.org/cordova/CommitterWorkflow -- Added Jesse's version
>of the "which branch - in code"
>http://wiki.apache.org/cordova/CuttingReleases -- Changed tagging
>instructions to refer to the "next" branch
>
>
>On Thu, Feb 7, 2013 at 1:26 PM, Marcel Kinard <cm...@gmail.com> wrote:
>
>> With 2.5 starting, it appears time to poke this thread.
>>
>> - Is the Google doc refreshed with the latest consensus?
>> - If so, should the Google doc be transferred to a wiki page?
>> - Have the necessary branches been created?
>> - Are we all in the boat, and understand how to row this beast?
>>
>> -- Marcel Kinard
>>
>> On Jan 24, 2013, at 5:14 PM, Jesse <pu...@gmail.com> wrote:
>>
>> > Nice Shaz, but I was hoping it was a github style network
>>visualization
>> > that included a few versions worth of merges.
>> > Who wants to draw that?
>> >
>> > On Thu, Jan 24, 2013 at 2:05 PM, Shazron <sh...@gmail.com> wrote:
>> >
>> >> Inline image got mangled, here it is linked: http://cl.ly/MOrD
>> >>
>> >>
>> >> On Thu, Jan 24, 2013 at 1:39 PM, Shazron <sh...@gmail.com> wrote:
>> >>
>> >>> Thanks for the pseudocode Andrew, seems simpler to understand ;)
>> Jesse's
>> >>> re-factor makes it even easier. Here's my contrib for those more
>> visually
>> >>> inclined:
>> >>>
>> >>>
>> >>> [image: Inline image 2]
>> >>>
>> >>>
>> >>> On Thu, Jan 24, 2013 at 1:29 PM, Andrew Grieve <agrieve@chromium.org
>> >wrote:
>> >>>
>> >>>> Nice! even simpler. :)
>> >>>>
>> >>>>
>> >>>> On Thu, Jan 24, 2013 at 3:44 PM, Jesse <pu...@gmail.com>
>> wrote:
>> >>>>
>> >>>>> Thanks for clarifying Andrew. et al, I guess I was
>>mis-understanding
>> >>>> some
>> >>>>> of the earlier discussion around naming stuff.
>> >>>>>
>> >>>>> So everything is going to master all the time, and we only care
>>about
>> >>>>> 'next' if we are inReleaseMode and it is a bug fix?
>> >>>>>
>> >>>>> if(inReleaseMode && isBugFix) {
>> >>>>> commitToBranch('next');
>> >>>>> mergeBranch('next').into('master');
>> >>>>> }
>> >>>>> else {
>> >>>>> commitToBranch('master');
>> >>>>> }
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> On Thu, Jan 24, 2013 at 12:29 PM, Andrew Grieve <
>> agrieve@chromium.org
>> >>>>>> wrote:
>> >>>>>
>> >>>>>> Just to clarify - there should be *no* using of the git
>> >>>> cherry-picking
>> >>>>>> command, only git merge.
>> >>>>>>
>> >>>>>> Jesse - not sure what you're referring to with "branch must be
>>named
>> >>>> x".
>> >>>>>> The latest revision of the proposal has only two branches: master
>> and
>> >>>>> next.
>> >>>>>> Do you mean you don't like the name "next"?
>> >>>>>>
>> >>>>>> Maybe the proposal will seem simpler if put in the form of code
>>:)
>> >>>>>>
>> >>>>>> if (!inReleaseMode) {
>> >>>>>> commitToBranch('master');
>> >>>>>> } else {
>> >>>>>> if (isBugFix) {
>> >>>>>> commitToBranch('next');
>> >>>>>> mergeBranch('next').into('master');
>> >>>>>> } else {
>> >>>>>> commitToBranch('master');
>> >>>>>> }
>> >>>>>> }
>> >>>>>>
>> >>>>>>
>> >>>>>> On Thu, Jan 24, 2013 at 3:06 PM, Braden Shepherdson <
>> >>>> braden@chromium.org
>> >>>>>>> wrote:
>> >>>>>>
>> >>>>>>> Most of the time the flow will be unchanged: push to master.
>> >>>> Tagging
>> >>>>>> things
>> >>>>>>> we already know how to do; that doesn't change.
>> >>>>>>>
>> >>>>>>> The only new flow for most people is cherrypicking bug fixes
>>from
>> >>>>> master
>> >>>>>> to
>> >>>>>>> next, which we can give examples of. Plus that could remain the
>> >>>>>>> responsibility of the main platform maintainers, who are doing
>>the
>> >>>>>> tagging.
>> >>>>>>>
>> >>>>>>> Braden
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> On Thu, Jan 24, 2013 at 2:56 PM, Jesse <pu...@gmail.com>
>> >>>>> wrote:
>> >>>>>>>
>> >>>>>>>> On Thu, Jan 24, 2013 at 11:09 AM, Braden Shepherdson <
>> >>>>>>> braden@chromium.org
>> >>>>>>>>> wrote:
>> >>>>>>>>
>> >>>>>>>>> The founding goal we're trying to accomplish here is that we
>> >>>> don't
>> >>>>>> want
>> >>>>>>>>> everyone sitting on changes to be in the next version while we
>> >>>> use
>> >>>>>>> master
>> >>>>>>>>> to prep a release.
>> >>>>>>>>>
>> >>>>>>>>> I don't think having one branch for prepping the release and
>> >>>>> another
>> >>>>>>> for
>> >>>>>>>>> main development is a lot of bureaucracy.
>> >>>>>>>>>
>> >>>>>>>>
>> >>>>>>>> It is not, the 'branch must be named x' is mainly where I have
>> >>>>>> concerns.
>> >>>>>>>> Really I just want things simple.
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> On Thu, Jan 24, 2013 at 1:57 PM, Jesse MacFadyen <
>> >>>>>>>> purplecabbage@gmail.com
>> >>>>>>>>>> wrote:
>> >>>>>>>>>
>> >>>>>>>>>> I have been quietly listening on this thread, but thought I
>> >>>>> should
>> >>>>>> at
>> >>>>>>>>>> least share my opinion.
>> >>>>>>>>>>
>> >>>>>>>>>> I don't think adding contribution rules helps anyone. Git is
>> >>>>>>>>>> complicated enough as it is, and this just all seems like
>> >>>>>>> bureaucracy.
>> >>>>>>>>>>
>> >>>>>>>>>> I think master should always contain the latest stable code,
>> >>>> and
>> >>>>> be
>> >>>>>>>>>> periodically tagged with rc's and versions.
>> >>>>>>>>>> All work should be done in personal forks and feature
>> >>>> branches.
>> >>>>>>>>>> If the latest tag of master is an rc, then we should only be
>> >>>>>> merging
>> >>>>>>>>>> bugfixes, until the release.
>> >>>>>>>>>> Immediately after tagging a version we decide which feature
>> >>>>>> branches
>> >>>>>>>>>> and pull requests to pull in, and go for it.
>> >>>>>>>>>>
>> >>>>>>>>>> I don't think this is much different from what we have, but I
>> >>>>> think
>> >>>>>>>>>> that is good.
>> >>>>>>>>>> The suggestions thus far, while interesting, don't increase
>> >>>> our
>> >>>>>>>>>> velocity in my opinion. Also, I can also pretty much guaranty
>> >>>>> I'll
>> >>>>>>>>>> screw it up for the next 3-4 versions. ( because I'm dumb )
>> >>>>>>>>>>
>> >>>>>>>>>> Cheers,
>> >>>>>>>>>> Jesse
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>> On 2013-01-24, at 5:53 AM, Andrew Grieve <
>> >>>> agrieve@chromium.org>
>> >>>>>>> wrote:
>> >>>>>>>>>>
>> >>>>>>>>>> On Wed, Jan 23, 2013 at 4:58 PM, Michael Brooks <
>> >>>>>>>>> michael@michaelbrooks.ca
>> >>>>>>>>>>> wrote:
>> >>>>>>>>>>
>> >>>>>>>>>>> Before we move forward, I have a few questions about the
>> >>>> "no
>> >>>>>>> master"
>> >>>>>>>>>>> approach.
>> >>>>>>>>>>>
>> >>>>>>>>>>> There is *no* master branch, so that community-driven pull
>> >>>>>> requests
>> >>>>>>>>> will
>> >>>>>>>>>> be
>> >>>>>>>>>>>> forced to think about which branch to request against.
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> - Andrew, can you cite other projects that do not use a
>> >>>> master
>> >>>>>>>> branch?
>> >>>>>>>>>> This project is my first time using git / github, so I don't
>> >>>> have
>> >>>>>>> much
>> >>>>>>>> to
>> >>>>>>>>>> draw from. I was going off of others' suggestions on this
>> >>>> thread
>> >>>>>>> when I
>> >>>>>>>>>> proposed the names.
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>> - On Github, you must have a default branch. If not
>> >>>> master, it
>> >>>>>> must
>> >>>>>>>> be
>> >>>>>>>>>>> something else. So, users are not forced to think about the
>> >>>>>> branch
>> >>>>>>> to
>> >>>>>>>>>> send
>> >>>>>>>>>>> a pull request again... they will likely just use the
>> >>>> default.
>> >>>>>>>>>>
>> >>>>>>>>>> Hmm, good point. The goal is to get people downloading
>> >>>> Cordova
>> >>>>> for
>> >>>>>>> use
>> >>>>>>>> to
>> >>>>>>>>>> end up with Stable, and for developers to send pull requests
>> >>>>>> against
>> >>>>>>>> dev.
>> >>>>>>>>>> With a forced default branch, I don't think we can accomplish
>> >>>>> this.
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> - Why is the "stable" branch not just "master"?
>> >>>>>>>>>>
>> >>>>>>>>>> My thinking was that it's not obvious whether Master ==
>> >>>> bleeding
>> >>>>>>> edge,
>> >>>>>>>> or
>> >>>>>>>>>> Master == Stable version. Using the names "dev" and "stable"
>> >>>>> makes
>> >>>>>>> it a
>> >>>>>>>>> bit
>> >>>>>>>>>> clear.
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>> So... If github forces us to have a default branch, I'm
>> >>>> thinking
>> >>>>>> that
>> >>>>>>>>>> having users send pull requests against "dev" is more
>> >>>> valuable
>> >>>>> than
>> >>>>>>>>> having
>> >>>>>>>>>> people download the latest "stable" by default. If people are
>> >>>>>> pulling
>> >>>>>>>>> code
>> >>>>>>>>>> from github rather than from our release .zip files, then
>> >>>> it's
>> >>>>>> likely
>> >>>>>>>>> they
>> >>>>>>>>>> want to hack on it anyways, or that they want the dev
>> >>>> version to
>> >>>>>> see
>> >>>>>>> if
>> >>>>>>>>>> bugs are fixed.
>> >>>>>>>>>>
>> >>>>>>>>>> Soo.... Here's version #3! If anyone can think of how to
>> >>>> keep the
>> >>>>>>> three
>> >>>>>>>>>> branches while addressing being forced to have a default
>> >>>> branch,
>> >>>>>> feel
>> >>>>>>>>> free
>> >>>>>>>>>> to speak up! :)
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>> Cordova repositories have two main branches:
>> >>>>>>>>>> 1. master
>> >>>>>>>>>> 2. next
>> >>>>>>>>>>
>> >>>>>>>>>> Topic branches exist for collaborating on features, or for
>> >>>>>>> code-review
>> >>>>>>>>>> purposes.
>> >>>>>>>>>>
>> >>>>>>>>>> Cordova uses tags to label releases.
>> >>>>>>>>>> - Each release candidate has a tag. e.g. "2.2.0rc1"
>> >>>>>>>>>> - Each release has a tag. e.g. "2.2.0"
>> >>>>>>>>>> - The "latest" tag points to the last stable release (this
>> >>>>> follows
>> >>>>>>> npm
>> >>>>>>>>>> conventions)
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>> 1. The "next" branch.
>> >>>>>>>>>> - This branch is used only when in the process of doing a
>> >>>>> release.
>> >>>>>>>>>> - All tags are created from this branch.
>> >>>>>>>>>> - All release-candidate bug-fixes are done on this branch.
>> >>>>>>>>>>
>> >>>>>>>>>> 2. The "master" branch.
>> >>>>>>>>>> - When not in the release-process, all commits are made here
>> >>>>>>>>>> - When in the release-process, all non-bugfix commits are
>> >>>> made
>> >>>>>> here
>> >>>>>>>>>> - This is where topic-branches are merged into.
>> >>>>>>>>>>
>> >>>>>>>>>> Cutting a release:
>> >>>>>>>>>> 1. git checkout next && git merge --ff-only master
>> >>>>>>>>>> 2. Test test test!
>> >>>>>>>>>> 3. Fix bugs by committing them directly to "next" and then
>> >>>> doing
>> >>>>> a
>> >>>>>>>> non-ff
>> >>>>>>>>>> merge of next into master
>> >>>>>>>>>> 4. Tag release candidate
>> >>>>>>>>>> 5. Repeat steps 2-4 as necessary
>> >>>>>>>>>> 6. Tag the release (both by version and by updating the
>> >>>> "latest"
>> >>>>>> tag)
>> >>>>>>>>>> 7. Create distribution .zip file
>> >>>>>>>>>> 8. Test one last time using the dist files
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> Thanks,
>> >>>>>>>>>>> Michael
>> >>>>>>>>>>>
>> >>>>>>>>>>> On Wed, Jan 23, 2013 at 11:25 AM, Brian LeRoux <b@brian.io
>> >>>>>
>> >>>>>> wrote:
>> >>>>>>>>>>>
>> >>>>>>>>>>>> I'm liking it. Start in 2.5?
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> On Wed, Jan 23, 2013 at 1:19 PM, Filip Maj <fil@adobe.com
>> >>>>>
>> >>>>>> wrote:
>> >>>>>>>>>>>>> Looks great Andrew!
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> If everyone's on board, how are we going to test run
>> >>>> this?
>> >>>>>> Flip a
>> >>>>>>>>>>> switch
>> >>>>>>>>>>>>> at a certain point, give it a shot with one repo for one
>> >>>> RC?
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> On 1/22/13 12:29 PM, "Andrew Grieve" <
>> >>>> agrieve@chromium.org>
>> >>>>>>> wrote:
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>> Braden, you're right. I've now done some local playing
>> >>>>> around
>> >>>>>> in
>> >>>>>>>>> git,
>> >>>>>>>>>>> and
>> >>>>>>>>>>>>>> have an updated proposal that uses merges instead of
>> >>>>> deleting
>> >>>>>>>>>> branches.
>> >>>>>>>>>>>>>> PTAL:
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> Cordova repositories have three main branches:
>> >>>>>>>>>>>>>> 1. stable
>> >>>>>>>>>>>>>> 2. next
>> >>>>>>>>>>>>>> 3. dev
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> Topic branches also exist for collaborating on
>> >>>> features, or
>> >>>>>> for
>> >>>>>>>>>>>>>> code-review
>> >>>>>>>>>>>>>> purposes.
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> There is *no* master branch, so that community-driven
>> >>>> pull
>> >>>>>>>> requests
>> >>>>>>>>>>> will
>> >>>>>>>>>>>>>> be
>> >>>>>>>>>>>>>> forced to think about which branch to request against.
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> 1. The "stable" branch.
>> >>>>>>>>>>>>>> - Sits at the latest stable release of cordova
>> >>>>>>>>>>>>>> - This changes only when doing fast-forward merges from
>> >>>>> "next"
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> 2. The "next" branch.
>> >>>>>>>>>>>>>> - This branch is used only when in the process of doing
>> >>>> a
>> >>>>>>> release.
>> >>>>>>>>>>>>>> - All tags (both stable and RC) are done on this branch.
>> >>>>>>>>>>>>>> - All release-candidate bug-fixes are done on this
>> >>>> branch.
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> 3. The "dev" branch.
>> >>>>>>>>>>>>>> - This is where non-release-candidate commits are done
>> >>>>>>>>>>>>>> - This is where topic-branches are merged into.
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> Cutting a release:
>> >>>>>>>>>>>>>> 1. git checkout next && git merge --ff-only dev
>> >>>>>>>>>>>>>> 2. Test test test!
>> >>>>>>>>>>>>>> 3. Fix bugs by committing them directly to "next" and
>> >>>> then
>> >>>>>>> doing a
>> >>>>>>>>>>> non-ff
>> >>>>>>>>>>>>>> merge of next into dev
>> >>>>>>>>>>>>>> 4. Tag release candidate
>> >>>>>>>>>>>>>> 5. Repeat steps 2-4 as necessary
>> >>>>>>>>>>>>>> 6. Tag the release
>> >>>>>>>>>>>>>> 7. Create distribution .zip file
>> >>>>>>>>>>>>>> 8. Test one last time using the dist files
>> >>>>>>>>>>>>>> 9. git checkout stable && git merge --ff-only next
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> On Tue, Jan 22, 2013 at 1:59 PM, Braden Shepherdson
>> >>>>>>>>>>>>>> <br...@chromium.org>wrote:
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> I think deleting and recreating branches with the same
>> >>>> name
>> >>>>>> can
>> >>>>>>>>> cause
>> >>>>>>>>>>>>>>> badness in git[1] because of remotes. It's not really
>> >>>> the
>> >>>>>> same
>> >>>>>>>>> branch
>> >>>>>>>>>>>> in
>> >>>>>>>>>>>>>>> terms of commits, and git thinks that your old stable
>> >>>> and
>> >>>>> the
>> >>>>>>> new
>> >>>>>>>>>>>> stable
>> >>>>>>>>>>>>>>> differ by all of each of their commits. Tags can be
>> >>>> moved
>> >>>>>>>>>>> arbitrarily,
>> >>>>>>>>>>>>>>> so I
>> >>>>>>>>>>>>>>> think stable makes sense as a tag. I'm not sure about
>> >>>> how
>> >>>>>> best
>> >>>>>>> to
>> >>>>>>>>>>>> handle
>> >>>>>>>>>>>>>>> next.
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> [1]
>> >>>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>
>> >>>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>>
>>http://stackoverflow.com/questions/11844581/git-delete-and-recreate-branc
>> >>>>>>>>>>>>>>> h
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> On Tue, Jan 22, 2013 at 11:31 AM, Andrew Grieve <
>> >>>>>>>>>>> agrieve@chromium.org
>> >>>>>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> Michal's attending hackathons for the week, and I'm
>> >>>> not
>> >>>>> sure
>> >>>>>>> we
>> >>>>>>>>>>> need
>> >>>>>>>>>>>>>>> to
>> >>>>>>>>>>>>>>> do
>> >>>>>>>>>>>>>>>> a hang-out for this, as I think we really are quite
>> >>>> close
>> >>>>> to
>> >>>>>>>>>>>> resolving
>> >>>>>>>>>>>>>>>> this. I'd really like to resolve this ASAP so that we
>> >>>>> don't
>> >>>>>>> need
>> >>>>>>>>> to
>> >>>>>>>>>>>>>>> have
>> >>>>>>>>>>>>>>> a
>> >>>>>>>>>>>>>>>> code-freeze for this release.
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> Here's a proposal:
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> Cordova repositories have three main branches:
>> >>>>>>>>>>>>>>>> 1. stable
>> >>>>>>>>>>>>>>>> 2. next
>> >>>>>>>>>>>>>>>> 3. dev
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> Topic branches also exist for collaborating on
>> >>>> features,
>> >>>>> or
>> >>>>>>> for
>> >>>>>>>>>>>>>>> code-review
>> >>>>>>>>>>>>>>>> purposes.
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> There is *no* master branch, so that community-driven
>> >>>> pull
>> >>>>>>>>> requests
>> >>>>>>>>>>>>>>> will
>> >>>>>>>>>>>>>>> be
>> >>>>>>>>>>>>>>>> forced to think about which branch to request against.
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> 1. The "stable" branch.
>> >>>>>>>>>>>>>>>> - Sits at the latest stable release of cordova
>> >>>>>>>>>>>>>>>> - No one ever commits to the "stable" branch. It
>> >>>> exists
>> >>>>> only
>> >>>>>>> as
>> >>>>>>>> a
>> >>>>>>>>>>>>>>>> short-cut for checking out the latest stable tag.
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> 2. The "next" branch.
>> >>>>>>>>>>>>>>>> - This branch exists only when in the process of
>> >>>> doing a
>> >>>>>>>> release.
>> >>>>>>>>>>>>>>>> - All tags (both stable and RC) are done on this
>> >>>> branch.
>> >>>>>>>>>>>>>>>> - When a stable tag is done:
>> >>>>>>>>>>>>>>>> - The existing "stable" branch is deleted
>> >>>>>>>>>>>>>>>> - A new "stable" branch is created from "next".
>> >>>>>>>>>>>>>>>> - The "next" branch is deleted.
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> 3. The "dev" branch.
>> >>>>>>>>>>>>>>>> - This is where all commits are done
>> >>>>>>>>>>>>>>>> - This is where topic-branches are merged into.
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> Cutting a release:
>> >>>>>>>>>>>>>>>> 1. Create "next" from the HEAD of "dev"
>> >>>>>>>>>>>>>>>> 2. Test test test!
>> >>>>>>>>>>>>>>>> 3. Fix bugs by committing them to "dev" and then
>> >>>>>>> cherry-picking
>> >>>>>>>>>>> them
>> >>>>>>>>>>>>>>> into
>> >>>>>>>>>>>>>>>> "next"
>> >>>>>>>>>>>>>>>> 4. Tag release candidate
>> >>>>>>>>>>>>>>>> 5. Repeat steps 2-4 as necessary
>> >>>>>>>>>>>>>>>> 6. Tag the release
>> >>>>>>>>>>>>>>>> 7. Create distribution .zip file
>> >>>>>>>>>>>>>>>> 8. Test one last time using the dist files
>> >>>>>>>>>>>>>>>> 9. Delete "stable"
>> >>>>>>>>>>>>>>>> 10. Create a new "stable" by branching from the HEAD
>> >>>> of
>> >>>>>> "next"
>> >>>>>>>>>>>>>>>> 11. Delete the "next" branch
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> On Wed, Jan 16, 2013 at 10:34 AM, Michal Mocny <
>> >>>>>>>>>>> mmocny@chromium.org>
>> >>>>>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>> Just going to throw out one of my personal
>> >>>> requirements
>> >>>>> for
>> >>>>>>>>>>>> whatever
>> >>>>>>>>>>>>>>>>> proposal we come up with, so it doesn't get lost:
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>> * Feature branches are great for feature work and/or
>> >>>>> large
>> >>>>>>>>>>> sweeping
>> >>>>>>>>>>>>>>>>> changes, as are JIRA bugs for tracking them, but
>> >>>> cordova
>> >>>>>> has
>> >>>>>>>> many
>> >>>>>>>>>>>>>>> many
>> >>>>>>>>>>>>>>>>> trivial issues that could be fixed with "drive-by"
>> >>>>> patches
>> >>>>>>> that
>> >>>>>>>>>>>>>>> require
>> >>>>>>>>>>>>>>>> as
>> >>>>>>>>>>>>>>>>> little friction to commit as possible.
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>> On Tue, Jan 15, 2013 at 3:05 PM, Marcel Kinard <
>> >>>>>>>>>>> cmarcelk@gmail.com
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>> How about if there is a specific straw man proposal
>> >>>> at
>> >>>>> the
>> >>>>>>>>>>>>>>> beginning
>> >>>>>>>>>>>>>>> of
>> >>>>>>>>>>>>>>>>>> the face-time? Then the folks that are in agreement
>> >>>>> won't
>> >>>>>>> need
>> >>>>>>>>>>> to
>> >>>>>>>>>>>>>>> say
>> >>>>>>>>>>>>>>>>>> anything ;-)
>> >>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>> Seriously, making adjustments to something tangible
>> >>>> is
>> >>>>>>> easier
>> >>>>>>>>>>>> than
>> >>>>>>>>>>>>>>>>>> instantiating it from scratch. A volunteer for a
>> >>>> very
>> >>>>>> simple
>> >>>>>>>>>>>>>>> writeup
>> >>>>>>>>>>>>>>> on
>> >>>>>>>>>>>>>>>>> the
>> >>>>>>>>>>>>>>>>>> wiki?
>> >>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>> -- Marcel Kinard
>> >>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>> On 1/14/2013 10:06 PM, Michal Mocny wrote:
>> >>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>> Okay gentlemen, I think there have been countless
>> >>>> good
>> >>>>>>> points
>> >>>>>>>>>>>>>>> made
>> >>>>>>>>>>>>>>>> from
>> >>>>>>>>>>>>>>>>>>> all
>> >>>>>>>>>>>>>>>>>>> parties, but also some bike-shedding.
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>> Perhaps it is time to schedule some face-time to
>> >>>> better
>> >>>>>>>>>>>>>>> articulate
>> >>>>>>>>>>>>>>>> some
>> >>>>>>>>>>>>>>>>> of
>> >>>>>>>>>>>>>>>>>>> the finer points, and to help come to some
>> >>>> consensus?
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>> -Michal
>> >>>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> --
>> >>>>>>>> @purplecabbage
>> >>>>>>>> risingj.com
>> >>>>>>>>
>> >>>>>>>
>> >>>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> --
>> >>>>> @purplecabbage
>> >>>>> risingj.com
>> >>>>>
>> >>>>
>> >>>
>> >>>
>> >>
>> >
>> >
>> > --
>> > @purplecabbage
>> > risingj.com
>>
>>
Re: too long to package a release?
Posted by Filip Maj <fi...@adobe.com>.
Right, that makes sense. In our specific case with all projects having a
VERSION file it should be a commit but I understand your point :)
On 2/20/13 11:55 AM, "Michal Mocny" <mm...@chromium.org> wrote:
>Fil: yes, that graph looks correct, with the added note that your rc/final
>point release "commits" are conceptually just tags. Its possible those
>also accompany a commit to change some versioning changes in text files,
>I'm not sure, but not necessarily.
>
>-Michal
>
>
>On Wed, Feb 20, 2013 at 2:47 PM, Filip Maj <fi...@adobe.com> wrote:
>
>> So when we release a final point release (that is a culmination of rcs,
>> i.e. 2.5.0rc1->2.5.0rc2->2.5.0), at that point on the next branch
>> effectively stops being in use.
>>
>> ASCII graph incoming of potential scenario
>>
>> Master Branch o--E---o--o--o--o--o--o--o--o
>> \ / / / \
>> Next Branch A--B--C--D F
>>
>> Where:
>>
>> A = initial rc1 commit (2.5.0rc1)
>> B = some regression bug fix
>> C = rc2 commit (2.5.0rc2)
>> D = final point release (2.5.0)
>> E = some feature that landed on master during release candidate time
>> F = rc1 commit for NEXT point release (2.6.0rc1)
>>
>> Does the above look correct?
>>
>> So in the end the git flow does not speed up our release time at all, it
>> just enables split-stream development (which is fine by me).
>>
>> The reason we are taking long to package a release is because the JS is
>>a
>> shared dependency across all platforms, and finding regressions in the
>>JS
>> requires a repackaging across all platforms.
>>
>> Until we can fully automate the packaging and tagging for platforms, and
>> testing on devices, we will be stuck with a (relatively speaking) slow
>> release process.
>>
>> On 2/20/13 11:34 AM, "Shazron" <sh...@gmail.com> wrote:
>>
>> > http://cl.ly/MOrD
>> >Master always has all the changes. Next will never have experimental
>> >changes/features after next is created, just bug fixes.
>> >
>> >On Wednesday, February 20, 2013, Joe Bowser wrote:
>> >
>> >> Honestly, this process is too complex and we should just go back to
>> >> what we were doing before. I don't think our git flow was what is
>> >> slowing us down.
>> >>
>> >>
>> >>
>> >> On Wed, Feb 20, 2013 at 11:22 AM, Filip Maj <fi...@adobe.com> wrote:
>> >> > Ok so the flow is: if you are committing into next, always merge
>>into
>> >> > master. Good. So the CI setup doesn't need to differentiate between
>> >> master
>> >> > and next. It can always pull from master.
>> >> >
>> >> > On 2/20/13 11:04 AM, "Andrew Grieve" <ag...@chromium.org> wrote:
>> >> >
>> >> >>Step 5 here: http://wiki.apache.org/cordova/CommitterWorkflow
>> >> >>
>> >> >>Probably it should be "isFixingRegression" instead of "isBugFix".
>>I'll
>> >> >>update it now.
>> >> >>
>> >> >>
>> >> >>On Wed, Feb 20, 2013 at 1:59 PM, Filip Maj <fi...@adobe.com> wrote:
>> >> >>
>> >> >>> I noticed on iOS the commits going into next are mirrored on
>>master.
>> >> >>>
>> >> >>> For Android that was not done.
>> >> >>>
>> >> >>> What is the correct process?
>> >> >>>
>> >> >>> On 2/20/13 10:12 AM, "Michal Mocny" <mm...@chromium.org> wrote:
>> >> >>>
>> >> >>> >oooo I didn't know that. Thanks!
>> >> >>> >
>> >> >>> >
>> >> >>> >On Wed, Feb 20, 2013 at 1:10 PM, Becky Gibson
>> >> >>> ><gi...@gmail.com>wrote:
>> >> >>> >
>> >> >>> >> Thank you, Michael! I do usually go a git push --dry-run to
>> >>check
>> >> >>>that
>> >> >>> >>I
>> >> >>> >> am pushing what I expect but I'll try the diff as well.
>> >> >>> >>
>> >> >>> >>
>> >> >>> >> On Wed, Feb 20, 2013 at 1:07 PM, Michal Mocny
>> >><mm...@chromium.org>
>> >> >>> >>wrote:
>> >> >>> >>
>> >> >>> >> > So there is also
>> http://wiki.apache.org/cordova/CuttingReleases
>> >> >>>which
>> >> >>> >> may
>> >> >>> >> > be useful (esp Taggin section).
>> >> >>> >> >
>> >> >>> >> > As far as the confusion with the two branch names:
>> >>"topic_branch"
>> >> >>>is
>> >> >>> >>your
>> >> >>> >> > local working branch for a bugfix/feature, and
>>"to_be_merged"
>> >>is
>> >> >>> >>really
>> >> >>> >> > "temporary_new_name_for_a_branch_to_do_rebase_in". I
>>usually
>> >>skip
>> >> >>> >>that
>> >> >>> >> > step and take the risk or rebasing in topic_branch (aside:
>>this
>> >> may
>> >> >>> >> > negatively affect diffs if you push updates for a
>> >> >>> >>review-edit-re-review
>> >> >>> >> > cycle -- but this isn't an issue for cordova).
>> >> >>> >> >
>> >> >>> >> > Do not checkout 'next' into your master branch. Update your
>> >>local
>> >> >>> >> branches
>> >> >>> >> > to include the remote next branch (with 'git pull apache'
>>with
>> >>no
>> >> >>> >>branch)
>> >> >>> >> > then you can switch to the next branch locally, apply your
>> >>patch
>> >> >>> >>there,
>> >> >>> >> and
>> >> >>> >> > push to that remote branch directly. Later, merge that
>>commit
>> >> into
>> >> >>> >> master
>> >> >>> >> > locally, and push that.
>> >> >>> >> >
>> >> >>> >> > Do not push to apache next from your local master, or else
>>you
>> >> will
>> >> >>> >>push
>> >> >>> >> > all the changes.
>> >> >>> >> >
>> >> >>> >> > I agree, this is a little confusing, but after a few
>>practice
>> >>runs
>> >> >>>it
>> >> >>> >> > should be easy to figure out. You should probably also
>>check
>> >>what
>> >> >>> >>would
>> >> >>> >> be
>> >> >>> >> > pushed with 'git diff apache/[target-branch]' or tag on
>>--stat
>> >>to
>> >> >>> >>that to
>> >> >>> >> > just see that files that would signal a quick "uh-oh".
>> >> >>> >> >
>> >> >>> >> > I'll work to update the wiki later today, and likely others
>> >>will
>> >> >>>have
>> >>
>>
>>
Re: too long to package a release?
Posted by Michal Mocny <mm...@chromium.org>.
Fil: yes, that graph looks correct, with the added note that your rc/final
point release "commits" are conceptually just tags. Its possible those
also accompany a commit to change some versioning changes in text files,
I'm not sure, but not necessarily.
-Michal
On Wed, Feb 20, 2013 at 2:47 PM, Filip Maj <fi...@adobe.com> wrote:
> So when we release a final point release (that is a culmination of rcs,
> i.e. 2.5.0rc1->2.5.0rc2->2.5.0), at that point on the next branch
> effectively stops being in use.
>
> ASCII graph incoming of potential scenario
>
> Master Branch o--E---o--o--o--o--o--o--o--o
> \ / / / \
> Next Branch A--B--C--D F
>
> Where:
>
> A = initial rc1 commit (2.5.0rc1)
> B = some regression bug fix
> C = rc2 commit (2.5.0rc2)
> D = final point release (2.5.0)
> E = some feature that landed on master during release candidate time
> F = rc1 commit for NEXT point release (2.6.0rc1)
>
> Does the above look correct?
>
> So in the end the git flow does not speed up our release time at all, it
> just enables split-stream development (which is fine by me).
>
> The reason we are taking long to package a release is because the JS is a
> shared dependency across all platforms, and finding regressions in the JS
> requires a repackaging across all platforms.
>
> Until we can fully automate the packaging and tagging for platforms, and
> testing on devices, we will be stuck with a (relatively speaking) slow
> release process.
>
> On 2/20/13 11:34 AM, "Shazron" <sh...@gmail.com> wrote:
>
> > http://cl.ly/MOrD
> >Master always has all the changes. Next will never have experimental
> >changes/features after next is created, just bug fixes.
> >
> >On Wednesday, February 20, 2013, Joe Bowser wrote:
> >
> >> Honestly, this process is too complex and we should just go back to
> >> what we were doing before. I don't think our git flow was what is
> >> slowing us down.
> >>
> >>
> >>
> >> On Wed, Feb 20, 2013 at 11:22 AM, Filip Maj <fi...@adobe.com> wrote:
> >> > Ok so the flow is: if you are committing into next, always merge into
> >> > master. Good. So the CI setup doesn't need to differentiate between
> >> master
> >> > and next. It can always pull from master.
> >> >
> >> > On 2/20/13 11:04 AM, "Andrew Grieve" <ag...@chromium.org> wrote:
> >> >
> >> >>Step 5 here: http://wiki.apache.org/cordova/CommitterWorkflow
> >> >>
> >> >>Probably it should be "isFixingRegression" instead of "isBugFix". I'll
> >> >>update it now.
> >> >>
> >> >>
> >> >>On Wed, Feb 20, 2013 at 1:59 PM, Filip Maj <fi...@adobe.com> wrote:
> >> >>
> >> >>> I noticed on iOS the commits going into next are mirrored on master.
> >> >>>
> >> >>> For Android that was not done.
> >> >>>
> >> >>> What is the correct process?
> >> >>>
> >> >>> On 2/20/13 10:12 AM, "Michal Mocny" <mm...@chromium.org> wrote:
> >> >>>
> >> >>> >oooo I didn't know that. Thanks!
> >> >>> >
> >> >>> >
> >> >>> >On Wed, Feb 20, 2013 at 1:10 PM, Becky Gibson
> >> >>> ><gi...@gmail.com>wrote:
> >> >>> >
> >> >>> >> Thank you, Michael! I do usually go a git push --dry-run to
> >>check
> >> >>>that
> >> >>> >>I
> >> >>> >> am pushing what I expect but I'll try the diff as well.
> >> >>> >>
> >> >>> >>
> >> >>> >> On Wed, Feb 20, 2013 at 1:07 PM, Michal Mocny
> >><mm...@chromium.org>
> >> >>> >>wrote:
> >> >>> >>
> >> >>> >> > So there is also
> http://wiki.apache.org/cordova/CuttingReleases
> >> >>>which
> >> >>> >> may
> >> >>> >> > be useful (esp Taggin section).
> >> >>> >> >
> >> >>> >> > As far as the confusion with the two branch names:
> >>"topic_branch"
> >> >>>is
> >> >>> >>your
> >> >>> >> > local working branch for a bugfix/feature, and "to_be_merged"
> >>is
> >> >>> >>really
> >> >>> >> > "temporary_new_name_for_a_branch_to_do_rebase_in". I usually
> >>skip
> >> >>> >>that
> >> >>> >> > step and take the risk or rebasing in topic_branch (aside: this
> >> may
> >> >>> >> > negatively affect diffs if you push updates for a
> >> >>> >>review-edit-re-review
> >> >>> >> > cycle -- but this isn't an issue for cordova).
> >> >>> >> >
> >> >>> >> > Do not checkout 'next' into your master branch. Update your
> >>local
> >> >>> >> branches
> >> >>> >> > to include the remote next branch (with 'git pull apache' with
> >>no
> >> >>> >>branch)
> >> >>> >> > then you can switch to the next branch locally, apply your
> >>patch
> >> >>> >>there,
> >> >>> >> and
> >> >>> >> > push to that remote branch directly. Later, merge that commit
> >> into
> >> >>> >> master
> >> >>> >> > locally, and push that.
> >> >>> >> >
> >> >>> >> > Do not push to apache next from your local master, or else you
> >> will
> >> >>> >>push
> >> >>> >> > all the changes.
> >> >>> >> >
> >> >>> >> > I agree, this is a little confusing, but after a few practice
> >>runs
> >> >>>it
> >> >>> >> > should be easy to figure out. You should probably also check
> >>what
> >> >>> >>would
> >> >>> >> be
> >> >>> >> > pushed with 'git diff apache/[target-branch]' or tag on --stat
> >>to
> >> >>> >>that to
> >> >>> >> > just see that files that would signal a quick "uh-oh".
> >> >>> >> >
> >> >>> >> > I'll work to update the wiki later today, and likely others
> >>will
> >> >>>have
> >>
>
>
Re: too long to package a release?
Posted by Filip Maj <fi...@adobe.com>.
I agree that it is necessary. Just want to make clear that split stream
dev won't speed up the release process (as the thread title implies).
On 2/20/13 11:57 AM, "Michal Mocny" <mm...@chromium.org> wrote:
>Also: Fil you are totally correct that this flow only really helps with
>split-stream dev, but considering how long it takes and often it happens
>(code freeze due to release) this seems kind of necessary. I think it is
>also a great foundation for automating packaging and tagging. So lets
>work
>on that, now.
>
>
>On Wed, Feb 20, 2013 at 2:53 PM, Andrew Grieve <ag...@chromium.org>
>wrote:
>
>> Fil - looks right to me.
>>
>> Added the git commands for committing into next to the wiki:
>>
>>
>> git checkout next
>> git pull apache
>> git checkout topic_branch
>> git rebase next -i
>> git checkout next
>> git merge --ff-only topic_branch
>> git push apache next
>> git branch -d topic_branch
>> git checkout master
>> git merge next
>> git push apache master
>>
>>
>>
>> On Wed, Feb 20, 2013 at 2:49 PM, Michal Mocny <mm...@chromium.org>
>>wrote:
>>
>> > Shaz sums it up perfect. Once we cut 'next' nothing goes in unless
>>its
>> > critical to it being a good release. Anything that goes into next
>>should
>> > almost by definition also go in to master.
>> >
>> > Note that this is functionally the same as only ever pushing to
>>master,
>> and
>> > cherry-picking certain commits into 'next'.
>> >
>> > -Michal
>> >
>> >
>> > On Wed, Feb 20, 2013 at 2:34 PM, Shazron <sh...@gmail.com> wrote:
>> >
>> > > http://cl.ly/MOrD
>> > > Master always has all the changes. Next will never have experimental
>> > > changes/features after next is created, just bug fixes.
>> > >
>> > > On Wednesday, February 20, 2013, Joe Bowser wrote:
>> > >
>> > > > Honestly, this process is too complex and we should just go back
>>to
>> > > > what we were doing before. I don't think our git flow was what is
>> > > > slowing us down.
>> > > >
>> > > >
>> > > >
>> > > > On Wed, Feb 20, 2013 at 11:22 AM, Filip Maj <fi...@adobe.com> wrote:
>> > > > > Ok so the flow is: if you are committing into next, always merge
>> into
>> > > > > master. Good. So the CI setup doesn't need to differentiate
>>between
>> > > > master
>> > > > > and next. It can always pull from master.
>> > > > >
>> > > > > On 2/20/13 11:04 AM, "Andrew Grieve" <ag...@chromium.org>
>>wrote:
>> > > > >
>> > > > >>Step 5 here: http://wiki.apache.org/cordova/CommitterWorkflow
>> > > > >>
>> > > > >>Probably it should be "isFixingRegression" instead of
>>"isBugFix".
>> > I'll
>> > > > >>update it now.
>> > > > >>
>> > > > >>
>> > > > >>On Wed, Feb 20, 2013 at 1:59 PM, Filip Maj <fi...@adobe.com>
>>wrote:
>> > > > >>
>> > > > >>> I noticed on iOS the commits going into next are mirrored on
>> > master.
>> > > > >>>
>> > > > >>> For Android that was not done.
>> > > > >>>
>> > > > >>> What is the correct process?
>> > > > >>>
>> > > > >>> On 2/20/13 10:12 AM, "Michal Mocny" <mm...@chromium.org>
>>wrote:
>> > > > >>>
>> > > > >>> >oooo I didn't know that. Thanks!
>> > > > >>> >
>> > > > >>> >
>> > > > >>> >On Wed, Feb 20, 2013 at 1:10 PM, Becky Gibson
>> > > > >>> ><gi...@gmail.com>wrote:
>> > > > >>> >
>> > > > >>> >> Thank you, Michael! I do usually go a git push --dry-run
>>to
>> > check
>> > > > >>>that
>> > > > >>> >>I
>> > > > >>> >> am pushing what I expect but I'll try the diff as well.
>> > > > >>> >>
>> > > > >>> >>
>> > > > >>> >> On Wed, Feb 20, 2013 at 1:07 PM, Michal Mocny <
>> > > mmocny@chromium.org>
>> > > > >>> >>wrote:
>> > > > >>> >>
>> > > > >>> >> > So there is also
>> > http://wiki.apache.org/cordova/CuttingReleases
>> > > > >>>which
>> > > > >>> >> may
>> > > > >>> >> > be useful (esp Taggin section).
>> > > > >>> >> >
>> > > > >>> >> > As far as the confusion with the two branch names:
>> > > "topic_branch"
>> > > > >>>is
>> > > > >>> >>your
>> > > > >>> >> > local working branch for a bugfix/feature, and
>> "to_be_merged"
>> > is
>> > > > >>> >>really
>> > > > >>> >> > "temporary_new_name_for_a_branch_to_do_rebase_in". I
>> usually
>> > > skip
>> > > > >>> >>that
>> > > > >>> >> > step and take the risk or rebasing in topic_branch
>>(aside:
>> > this
>> > > > may
>> > > > >>> >> > negatively affect diffs if you push updates for a
>> > > > >>> >>review-edit-re-review
>> > > > >>> >> > cycle -- but this isn't an issue for cordova).
>> > > > >>> >> >
>> > > > >>> >> > Do not checkout 'next' into your master branch. Update
>>your
>> > > local
>> > > > >>> >> branches
>> > > > >>> >> > to include the remote next branch (with 'git pull apache'
>> with
>> > > no
>> > > > >>> >>branch)
>> > > > >>> >> > then you can switch to the next branch locally, apply
>>your
>> > patch
>> > > > >>> >>there,
>> > > > >>> >> and
>> > > > >>> >> > push to that remote branch directly. Later, merge that
>> commit
>> > > > into
>> > > > >>> >> master
>> > > > >>> >> > locally, and push that.
>> > > > >>> >> >
>> > > > >>> >> > Do not push to apache next from your local master, or
>>else
>> you
>> > > > will
>> > > > >>> >>push
>> > > > >>> >> > all the changes.
>> > > > >>> >> >
>> > > > >>> >> > I agree, this is a little confusing, but after a few
>> practice
>> > > runs
>> > > > >>>it
>> > > > >>> >> > should be easy to figure out. You should probably also
>> check
>> > > what
>> > > > >>> >>would
>> > > > >>> >> be
>> > > > >>> >> > pushed with 'git diff apache/[target-branch]' or tag on
>> --stat
>> > > to
>> > > > >>> >>that to
>> > > > >>> >> > just see that files that would signal a quick "uh-oh".
>> > > > >>> >> >
>> > > > >>> >> > I'll work to update the wiki later today, and likely
>>others
>> > will
>> > > > >>>have
>> > > >
>> > >
>> >
>>
Re: too long to package a release?
Posted by Michal Mocny <mm...@chromium.org>.
Also: Fil you are totally correct that this flow only really helps with
split-stream dev, but considering how long it takes and often it happens
(code freeze due to release) this seems kind of necessary. I think it is
also a great foundation for automating packaging and tagging. So lets work
on that, now.
On Wed, Feb 20, 2013 at 2:53 PM, Andrew Grieve <ag...@chromium.org> wrote:
> Fil - looks right to me.
>
> Added the git commands for committing into next to the wiki:
>
>
> git checkout next
> git pull apache
> git checkout topic_branch
> git rebase next -i
> git checkout next
> git merge --ff-only topic_branch
> git push apache next
> git branch -d topic_branch
> git checkout master
> git merge next
> git push apache master
>
>
>
> On Wed, Feb 20, 2013 at 2:49 PM, Michal Mocny <mm...@chromium.org> wrote:
>
> > Shaz sums it up perfect. Once we cut 'next' nothing goes in unless its
> > critical to it being a good release. Anything that goes into next should
> > almost by definition also go in to master.
> >
> > Note that this is functionally the same as only ever pushing to master,
> and
> > cherry-picking certain commits into 'next'.
> >
> > -Michal
> >
> >
> > On Wed, Feb 20, 2013 at 2:34 PM, Shazron <sh...@gmail.com> wrote:
> >
> > > http://cl.ly/MOrD
> > > Master always has all the changes. Next will never have experimental
> > > changes/features after next is created, just bug fixes.
> > >
> > > On Wednesday, February 20, 2013, Joe Bowser wrote:
> > >
> > > > Honestly, this process is too complex and we should just go back to
> > > > what we were doing before. I don't think our git flow was what is
> > > > slowing us down.
> > > >
> > > >
> > > >
> > > > On Wed, Feb 20, 2013 at 11:22 AM, Filip Maj <fi...@adobe.com> wrote:
> > > > > Ok so the flow is: if you are committing into next, always merge
> into
> > > > > master. Good. So the CI setup doesn't need to differentiate between
> > > > master
> > > > > and next. It can always pull from master.
> > > > >
> > > > > On 2/20/13 11:04 AM, "Andrew Grieve" <ag...@chromium.org> wrote:
> > > > >
> > > > >>Step 5 here: http://wiki.apache.org/cordova/CommitterWorkflow
> > > > >>
> > > > >>Probably it should be "isFixingRegression" instead of "isBugFix".
> > I'll
> > > > >>update it now.
> > > > >>
> > > > >>
> > > > >>On Wed, Feb 20, 2013 at 1:59 PM, Filip Maj <fi...@adobe.com> wrote:
> > > > >>
> > > > >>> I noticed on iOS the commits going into next are mirrored on
> > master.
> > > > >>>
> > > > >>> For Android that was not done.
> > > > >>>
> > > > >>> What is the correct process?
> > > > >>>
> > > > >>> On 2/20/13 10:12 AM, "Michal Mocny" <mm...@chromium.org> wrote:
> > > > >>>
> > > > >>> >oooo I didn't know that. Thanks!
> > > > >>> >
> > > > >>> >
> > > > >>> >On Wed, Feb 20, 2013 at 1:10 PM, Becky Gibson
> > > > >>> ><gi...@gmail.com>wrote:
> > > > >>> >
> > > > >>> >> Thank you, Michael! I do usually go a git push --dry-run to
> > check
> > > > >>>that
> > > > >>> >>I
> > > > >>> >> am pushing what I expect but I'll try the diff as well.
> > > > >>> >>
> > > > >>> >>
> > > > >>> >> On Wed, Feb 20, 2013 at 1:07 PM, Michal Mocny <
> > > mmocny@chromium.org>
> > > > >>> >>wrote:
> > > > >>> >>
> > > > >>> >> > So there is also
> > http://wiki.apache.org/cordova/CuttingReleases
> > > > >>>which
> > > > >>> >> may
> > > > >>> >> > be useful (esp Taggin section).
> > > > >>> >> >
> > > > >>> >> > As far as the confusion with the two branch names:
> > > "topic_branch"
> > > > >>>is
> > > > >>> >>your
> > > > >>> >> > local working branch for a bugfix/feature, and
> "to_be_merged"
> > is
> > > > >>> >>really
> > > > >>> >> > "temporary_new_name_for_a_branch_to_do_rebase_in". I
> usually
> > > skip
> > > > >>> >>that
> > > > >>> >> > step and take the risk or rebasing in topic_branch (aside:
> > this
> > > > may
> > > > >>> >> > negatively affect diffs if you push updates for a
> > > > >>> >>review-edit-re-review
> > > > >>> >> > cycle -- but this isn't an issue for cordova).
> > > > >>> >> >
> > > > >>> >> > Do not checkout 'next' into your master branch. Update your
> > > local
> > > > >>> >> branches
> > > > >>> >> > to include the remote next branch (with 'git pull apache'
> with
> > > no
> > > > >>> >>branch)
> > > > >>> >> > then you can switch to the next branch locally, apply your
> > patch
> > > > >>> >>there,
> > > > >>> >> and
> > > > >>> >> > push to that remote branch directly. Later, merge that
> commit
> > > > into
> > > > >>> >> master
> > > > >>> >> > locally, and push that.
> > > > >>> >> >
> > > > >>> >> > Do not push to apache next from your local master, or else
> you
> > > > will
> > > > >>> >>push
> > > > >>> >> > all the changes.
> > > > >>> >> >
> > > > >>> >> > I agree, this is a little confusing, but after a few
> practice
> > > runs
> > > > >>>it
> > > > >>> >> > should be easy to figure out. You should probably also
> check
> > > what
> > > > >>> >>would
> > > > >>> >> be
> > > > >>> >> > pushed with 'git diff apache/[target-branch]' or tag on
> --stat
> > > to
> > > > >>> >>that to
> > > > >>> >> > just see that files that would signal a quick "uh-oh".
> > > > >>> >> >
> > > > >>> >> > I'll work to update the wiki later today, and likely others
> > will
> > > > >>>have
> > > >
> > >
> >
>
Re: too long to package a release?
Posted by Andrew Grieve <ag...@chromium.org>.
Fil - looks right to me.
Added the git commands for committing into next to the wiki:
git checkout next
git pull apache
git checkout topic_branch
git rebase next -i
git checkout next
git merge --ff-only topic_branch
git push apache next
git branch -d topic_branch
git checkout master
git merge next
git push apache master
On Wed, Feb 20, 2013 at 2:49 PM, Michal Mocny <mm...@chromium.org> wrote:
> Shaz sums it up perfect. Once we cut 'next' nothing goes in unless its
> critical to it being a good release. Anything that goes into next should
> almost by definition also go in to master.
>
> Note that this is functionally the same as only ever pushing to master, and
> cherry-picking certain commits into 'next'.
>
> -Michal
>
>
> On Wed, Feb 20, 2013 at 2:34 PM, Shazron <sh...@gmail.com> wrote:
>
> > http://cl.ly/MOrD
> > Master always has all the changes. Next will never have experimental
> > changes/features after next is created, just bug fixes.
> >
> > On Wednesday, February 20, 2013, Joe Bowser wrote:
> >
> > > Honestly, this process is too complex and we should just go back to
> > > what we were doing before. I don't think our git flow was what is
> > > slowing us down.
> > >
> > >
> > >
> > > On Wed, Feb 20, 2013 at 11:22 AM, Filip Maj <fi...@adobe.com> wrote:
> > > > Ok so the flow is: if you are committing into next, always merge into
> > > > master. Good. So the CI setup doesn't need to differentiate between
> > > master
> > > > and next. It can always pull from master.
> > > >
> > > > On 2/20/13 11:04 AM, "Andrew Grieve" <ag...@chromium.org> wrote:
> > > >
> > > >>Step 5 here: http://wiki.apache.org/cordova/CommitterWorkflow
> > > >>
> > > >>Probably it should be "isFixingRegression" instead of "isBugFix".
> I'll
> > > >>update it now.
> > > >>
> > > >>
> > > >>On Wed, Feb 20, 2013 at 1:59 PM, Filip Maj <fi...@adobe.com> wrote:
> > > >>
> > > >>> I noticed on iOS the commits going into next are mirrored on
> master.
> > > >>>
> > > >>> For Android that was not done.
> > > >>>
> > > >>> What is the correct process?
> > > >>>
> > > >>> On 2/20/13 10:12 AM, "Michal Mocny" <mm...@chromium.org> wrote:
> > > >>>
> > > >>> >oooo I didn't know that. Thanks!
> > > >>> >
> > > >>> >
> > > >>> >On Wed, Feb 20, 2013 at 1:10 PM, Becky Gibson
> > > >>> ><gi...@gmail.com>wrote:
> > > >>> >
> > > >>> >> Thank you, Michael! I do usually go a git push --dry-run to
> check
> > > >>>that
> > > >>> >>I
> > > >>> >> am pushing what I expect but I'll try the diff as well.
> > > >>> >>
> > > >>> >>
> > > >>> >> On Wed, Feb 20, 2013 at 1:07 PM, Michal Mocny <
> > mmocny@chromium.org>
> > > >>> >>wrote:
> > > >>> >>
> > > >>> >> > So there is also
> http://wiki.apache.org/cordova/CuttingReleases
> > > >>>which
> > > >>> >> may
> > > >>> >> > be useful (esp Taggin section).
> > > >>> >> >
> > > >>> >> > As far as the confusion with the two branch names:
> > "topic_branch"
> > > >>>is
> > > >>> >>your
> > > >>> >> > local working branch for a bugfix/feature, and "to_be_merged"
> is
> > > >>> >>really
> > > >>> >> > "temporary_new_name_for_a_branch_to_do_rebase_in". I usually
> > skip
> > > >>> >>that
> > > >>> >> > step and take the risk or rebasing in topic_branch (aside:
> this
> > > may
> > > >>> >> > negatively affect diffs if you push updates for a
> > > >>> >>review-edit-re-review
> > > >>> >> > cycle -- but this isn't an issue for cordova).
> > > >>> >> >
> > > >>> >> > Do not checkout 'next' into your master branch. Update your
> > local
> > > >>> >> branches
> > > >>> >> > to include the remote next branch (with 'git pull apache' with
> > no
> > > >>> >>branch)
> > > >>> >> > then you can switch to the next branch locally, apply your
> patch
> > > >>> >>there,
> > > >>> >> and
> > > >>> >> > push to that remote branch directly. Later, merge that commit
> > > into
> > > >>> >> master
> > > >>> >> > locally, and push that.
> > > >>> >> >
> > > >>> >> > Do not push to apache next from your local master, or else you
> > > will
> > > >>> >>push
> > > >>> >> > all the changes.
> > > >>> >> >
> > > >>> >> > I agree, this is a little confusing, but after a few practice
> > runs
> > > >>>it
> > > >>> >> > should be easy to figure out. You should probably also check
> > what
> > > >>> >>would
> > > >>> >> be
> > > >>> >> > pushed with 'git diff apache/[target-branch]' or tag on --stat
> > to
> > > >>> >>that to
> > > >>> >> > just see that files that would signal a quick "uh-oh".
> > > >>> >> >
> > > >>> >> > I'll work to update the wiki later today, and likely others
> will
> > > >>>have
> > >
> >
>
Re: too long to package a release?
Posted by Michal Mocny <mm...@chromium.org>.
Shaz sums it up perfect. Once we cut 'next' nothing goes in unless its
critical to it being a good release. Anything that goes into next should
almost by definition also go in to master.
Note that this is functionally the same as only ever pushing to master, and
cherry-picking certain commits into 'next'.
-Michal
On Wed, Feb 20, 2013 at 2:34 PM, Shazron <sh...@gmail.com> wrote:
> http://cl.ly/MOrD
> Master always has all the changes. Next will never have experimental
> changes/features after next is created, just bug fixes.
>
> On Wednesday, February 20, 2013, Joe Bowser wrote:
>
> > Honestly, this process is too complex and we should just go back to
> > what we were doing before. I don't think our git flow was what is
> > slowing us down.
> >
> >
> >
> > On Wed, Feb 20, 2013 at 11:22 AM, Filip Maj <fi...@adobe.com> wrote:
> > > Ok so the flow is: if you are committing into next, always merge into
> > > master. Good. So the CI setup doesn't need to differentiate between
> > master
> > > and next. It can always pull from master.
> > >
> > > On 2/20/13 11:04 AM, "Andrew Grieve" <ag...@chromium.org> wrote:
> > >
> > >>Step 5 here: http://wiki.apache.org/cordova/CommitterWorkflow
> > >>
> > >>Probably it should be "isFixingRegression" instead of "isBugFix". I'll
> > >>update it now.
> > >>
> > >>
> > >>On Wed, Feb 20, 2013 at 1:59 PM, Filip Maj <fi...@adobe.com> wrote:
> > >>
> > >>> I noticed on iOS the commits going into next are mirrored on master.
> > >>>
> > >>> For Android that was not done.
> > >>>
> > >>> What is the correct process?
> > >>>
> > >>> On 2/20/13 10:12 AM, "Michal Mocny" <mm...@chromium.org> wrote:
> > >>>
> > >>> >oooo I didn't know that. Thanks!
> > >>> >
> > >>> >
> > >>> >On Wed, Feb 20, 2013 at 1:10 PM, Becky Gibson
> > >>> ><gi...@gmail.com>wrote:
> > >>> >
> > >>> >> Thank you, Michael! I do usually go a git push --dry-run to check
> > >>>that
> > >>> >>I
> > >>> >> am pushing what I expect but I'll try the diff as well.
> > >>> >>
> > >>> >>
> > >>> >> On Wed, Feb 20, 2013 at 1:07 PM, Michal Mocny <
> mmocny@chromium.org>
> > >>> >>wrote:
> > >>> >>
> > >>> >> > So there is also http://wiki.apache.org/cordova/CuttingReleases
> > >>>which
> > >>> >> may
> > >>> >> > be useful (esp Taggin section).
> > >>> >> >
> > >>> >> > As far as the confusion with the two branch names:
> "topic_branch"
> > >>>is
> > >>> >>your
> > >>> >> > local working branch for a bugfix/feature, and "to_be_merged" is
> > >>> >>really
> > >>> >> > "temporary_new_name_for_a_branch_to_do_rebase_in". I usually
> skip
> > >>> >>that
> > >>> >> > step and take the risk or rebasing in topic_branch (aside: this
> > may
> > >>> >> > negatively affect diffs if you push updates for a
> > >>> >>review-edit-re-review
> > >>> >> > cycle -- but this isn't an issue for cordova).
> > >>> >> >
> > >>> >> > Do not checkout 'next' into your master branch. Update your
> local
> > >>> >> branches
> > >>> >> > to include the remote next branch (with 'git pull apache' with
> no
> > >>> >>branch)
> > >>> >> > then you can switch to the next branch locally, apply your patch
> > >>> >>there,
> > >>> >> and
> > >>> >> > push to that remote branch directly. Later, merge that commit
> > into
> > >>> >> master
> > >>> >> > locally, and push that.
> > >>> >> >
> > >>> >> > Do not push to apache next from your local master, or else you
> > will
> > >>> >>push
> > >>> >> > all the changes.
> > >>> >> >
> > >>> >> > I agree, this is a little confusing, but after a few practice
> runs
> > >>>it
> > >>> >> > should be easy to figure out. You should probably also check
> what
> > >>> >>would
> > >>> >> be
> > >>> >> > pushed with 'git diff apache/[target-branch]' or tag on --stat
> to
> > >>> >>that to
> > >>> >> > just see that files that would signal a quick "uh-oh".
> > >>> >> >
> > >>> >> > I'll work to update the wiki later today, and likely others will
> > >>>have
> >
>
Re: too long to package a release?
Posted by Filip Maj <fi...@adobe.com>.
So when we release a final point release (that is a culmination of rcs,
i.e. 2.5.0rc1->2.5.0rc2->2.5.0), at that point on the next branch
effectively stops being in use.
ASCII graph incoming of potential scenario
Master Branch o--E---o--o--o--o--o--o--o--o
\ / / / \
Next Branch A--B--C--D F
Where:
A = initial rc1 commit (2.5.0rc1)
B = some regression bug fix
C = rc2 commit (2.5.0rc2)
D = final point release (2.5.0)
E = some feature that landed on master during release candidate time
F = rc1 commit for NEXT point release (2.6.0rc1)
Does the above look correct?
So in the end the git flow does not speed up our release time at all, it
just enables split-stream development (which is fine by me).
The reason we are taking long to package a release is because the JS is a
shared dependency across all platforms, and finding regressions in the JS
requires a repackaging across all platforms.
Until we can fully automate the packaging and tagging for platforms, and
testing on devices, we will be stuck with a (relatively speaking) slow
release process.
On 2/20/13 11:34 AM, "Shazron" <sh...@gmail.com> wrote:
> http://cl.ly/MOrD
>Master always has all the changes. Next will never have experimental
>changes/features after next is created, just bug fixes.
>
>On Wednesday, February 20, 2013, Joe Bowser wrote:
>
>> Honestly, this process is too complex and we should just go back to
>> what we were doing before. I don't think our git flow was what is
>> slowing us down.
>>
>>
>>
>> On Wed, Feb 20, 2013 at 11:22 AM, Filip Maj <fi...@adobe.com> wrote:
>> > Ok so the flow is: if you are committing into next, always merge into
>> > master. Good. So the CI setup doesn't need to differentiate between
>> master
>> > and next. It can always pull from master.
>> >
>> > On 2/20/13 11:04 AM, "Andrew Grieve" <ag...@chromium.org> wrote:
>> >
>> >>Step 5 here: http://wiki.apache.org/cordova/CommitterWorkflow
>> >>
>> >>Probably it should be "isFixingRegression" instead of "isBugFix". I'll
>> >>update it now.
>> >>
>> >>
>> >>On Wed, Feb 20, 2013 at 1:59 PM, Filip Maj <fi...@adobe.com> wrote:
>> >>
>> >>> I noticed on iOS the commits going into next are mirrored on master.
>> >>>
>> >>> For Android that was not done.
>> >>>
>> >>> What is the correct process?
>> >>>
>> >>> On 2/20/13 10:12 AM, "Michal Mocny" <mm...@chromium.org> wrote:
>> >>>
>> >>> >oooo I didn't know that. Thanks!
>> >>> >
>> >>> >
>> >>> >On Wed, Feb 20, 2013 at 1:10 PM, Becky Gibson
>> >>> ><gi...@gmail.com>wrote:
>> >>> >
>> >>> >> Thank you, Michael! I do usually go a git push --dry-run to
>>check
>> >>>that
>> >>> >>I
>> >>> >> am pushing what I expect but I'll try the diff as well.
>> >>> >>
>> >>> >>
>> >>> >> On Wed, Feb 20, 2013 at 1:07 PM, Michal Mocny
>><mm...@chromium.org>
>> >>> >>wrote:
>> >>> >>
>> >>> >> > So there is also http://wiki.apache.org/cordova/CuttingReleases
>> >>>which
>> >>> >> may
>> >>> >> > be useful (esp Taggin section).
>> >>> >> >
>> >>> >> > As far as the confusion with the two branch names:
>>"topic_branch"
>> >>>is
>> >>> >>your
>> >>> >> > local working branch for a bugfix/feature, and "to_be_merged"
>>is
>> >>> >>really
>> >>> >> > "temporary_new_name_for_a_branch_to_do_rebase_in". I usually
>>skip
>> >>> >>that
>> >>> >> > step and take the risk or rebasing in topic_branch (aside: this
>> may
>> >>> >> > negatively affect diffs if you push updates for a
>> >>> >>review-edit-re-review
>> >>> >> > cycle -- but this isn't an issue for cordova).
>> >>> >> >
>> >>> >> > Do not checkout 'next' into your master branch. Update your
>>local
>> >>> >> branches
>> >>> >> > to include the remote next branch (with 'git pull apache' with
>>no
>> >>> >>branch)
>> >>> >> > then you can switch to the next branch locally, apply your
>>patch
>> >>> >>there,
>> >>> >> and
>> >>> >> > push to that remote branch directly. Later, merge that commit
>> into
>> >>> >> master
>> >>> >> > locally, and push that.
>> >>> >> >
>> >>> >> > Do not push to apache next from your local master, or else you
>> will
>> >>> >>push
>> >>> >> > all the changes.
>> >>> >> >
>> >>> >> > I agree, this is a little confusing, but after a few practice
>>runs
>> >>>it
>> >>> >> > should be easy to figure out. You should probably also check
>>what
>> >>> >>would
>> >>> >> be
>> >>> >> > pushed with 'git diff apache/[target-branch]' or tag on --stat
>>to
>> >>> >>that to
>> >>> >> > just see that files that would signal a quick "uh-oh".
>> >>> >> >
>> >>> >> > I'll work to update the wiki later today, and likely others
>>will
>> >>>have
>>
Re: too long to package a release?
Posted by Shazron <sh...@gmail.com>.
http://cl.ly/MOrD
Master always has all the changes. Next will never have experimental
changes/features after next is created, just bug fixes.
On Wednesday, February 20, 2013, Joe Bowser wrote:
> Honestly, this process is too complex and we should just go back to
> what we were doing before. I don't think our git flow was what is
> slowing us down.
>
>
>
> On Wed, Feb 20, 2013 at 11:22 AM, Filip Maj <fi...@adobe.com> wrote:
> > Ok so the flow is: if you are committing into next, always merge into
> > master. Good. So the CI setup doesn't need to differentiate between
> master
> > and next. It can always pull from master.
> >
> > On 2/20/13 11:04 AM, "Andrew Grieve" <ag...@chromium.org> wrote:
> >
> >>Step 5 here: http://wiki.apache.org/cordova/CommitterWorkflow
> >>
> >>Probably it should be "isFixingRegression" instead of "isBugFix". I'll
> >>update it now.
> >>
> >>
> >>On Wed, Feb 20, 2013 at 1:59 PM, Filip Maj <fi...@adobe.com> wrote:
> >>
> >>> I noticed on iOS the commits going into next are mirrored on master.
> >>>
> >>> For Android that was not done.
> >>>
> >>> What is the correct process?
> >>>
> >>> On 2/20/13 10:12 AM, "Michal Mocny" <mm...@chromium.org> wrote:
> >>>
> >>> >oooo I didn't know that. Thanks!
> >>> >
> >>> >
> >>> >On Wed, Feb 20, 2013 at 1:10 PM, Becky Gibson
> >>> ><gi...@gmail.com>wrote:
> >>> >
> >>> >> Thank you, Michael! I do usually go a git push --dry-run to check
> >>>that
> >>> >>I
> >>> >> am pushing what I expect but I'll try the diff as well.
> >>> >>
> >>> >>
> >>> >> On Wed, Feb 20, 2013 at 1:07 PM, Michal Mocny <mm...@chromium.org>
> >>> >>wrote:
> >>> >>
> >>> >> > So there is also http://wiki.apache.org/cordova/CuttingReleases
> >>>which
> >>> >> may
> >>> >> > be useful (esp Taggin section).
> >>> >> >
> >>> >> > As far as the confusion with the two branch names: "topic_branch"
> >>>is
> >>> >>your
> >>> >> > local working branch for a bugfix/feature, and "to_be_merged" is
> >>> >>really
> >>> >> > "temporary_new_name_for_a_branch_to_do_rebase_in". I usually skip
> >>> >>that
> >>> >> > step and take the risk or rebasing in topic_branch (aside: this
> may
> >>> >> > negatively affect diffs if you push updates for a
> >>> >>review-edit-re-review
> >>> >> > cycle -- but this isn't an issue for cordova).
> >>> >> >
> >>> >> > Do not checkout 'next' into your master branch. Update your local
> >>> >> branches
> >>> >> > to include the remote next branch (with 'git pull apache' with no
> >>> >>branch)
> >>> >> > then you can switch to the next branch locally, apply your patch
> >>> >>there,
> >>> >> and
> >>> >> > push to that remote branch directly. Later, merge that commit
> into
> >>> >> master
> >>> >> > locally, and push that.
> >>> >> >
> >>> >> > Do not push to apache next from your local master, or else you
> will
> >>> >>push
> >>> >> > all the changes.
> >>> >> >
> >>> >> > I agree, this is a little confusing, but after a few practice runs
> >>>it
> >>> >> > should be easy to figure out. You should probably also check what
> >>> >>would
> >>> >> be
> >>> >> > pushed with 'git diff apache/[target-branch]' or tag on --stat to
> >>> >>that to
> >>> >> > just see that files that would signal a quick "uh-oh".
> >>> >> >
> >>> >> > I'll work to update the wiki later today, and likely others will
> >>>have
>
Re: too long to package a release?
Posted by Joe Bowser <bo...@gmail.com>.
Honestly, this process is too complex and we should just go back to
what we were doing before. I don't think our git flow was what is
slowing us down.
On Wed, Feb 20, 2013 at 11:22 AM, Filip Maj <fi...@adobe.com> wrote:
> Ok so the flow is: if you are committing into next, always merge into
> master. Good. So the CI setup doesn't need to differentiate between master
> and next. It can always pull from master.
>
> On 2/20/13 11:04 AM, "Andrew Grieve" <ag...@chromium.org> wrote:
>
>>Step 5 here: http://wiki.apache.org/cordova/CommitterWorkflow
>>
>>Probably it should be "isFixingRegression" instead of "isBugFix". I'll
>>update it now.
>>
>>
>>On Wed, Feb 20, 2013 at 1:59 PM, Filip Maj <fi...@adobe.com> wrote:
>>
>>> I noticed on iOS the commits going into next are mirrored on master.
>>>
>>> For Android that was not done.
>>>
>>> What is the correct process?
>>>
>>> On 2/20/13 10:12 AM, "Michal Mocny" <mm...@chromium.org> wrote:
>>>
>>> >oooo I didn't know that. Thanks!
>>> >
>>> >
>>> >On Wed, Feb 20, 2013 at 1:10 PM, Becky Gibson
>>> ><gi...@gmail.com>wrote:
>>> >
>>> >> Thank you, Michael! I do usually go a git push --dry-run to check
>>>that
>>> >>I
>>> >> am pushing what I expect but I'll try the diff as well.
>>> >>
>>> >>
>>> >> On Wed, Feb 20, 2013 at 1:07 PM, Michal Mocny <mm...@chromium.org>
>>> >>wrote:
>>> >>
>>> >> > So there is also http://wiki.apache.org/cordova/CuttingReleases
>>>which
>>> >> may
>>> >> > be useful (esp Taggin section).
>>> >> >
>>> >> > As far as the confusion with the two branch names: "topic_branch"
>>>is
>>> >>your
>>> >> > local working branch for a bugfix/feature, and "to_be_merged" is
>>> >>really
>>> >> > "temporary_new_name_for_a_branch_to_do_rebase_in". I usually skip
>>> >>that
>>> >> > step and take the risk or rebasing in topic_branch (aside: this may
>>> >> > negatively affect diffs if you push updates for a
>>> >>review-edit-re-review
>>> >> > cycle -- but this isn't an issue for cordova).
>>> >> >
>>> >> > Do not checkout 'next' into your master branch. Update your local
>>> >> branches
>>> >> > to include the remote next branch (with 'git pull apache' with no
>>> >>branch)
>>> >> > then you can switch to the next branch locally, apply your patch
>>> >>there,
>>> >> and
>>> >> > push to that remote branch directly. Later, merge that commit into
>>> >> master
>>> >> > locally, and push that.
>>> >> >
>>> >> > Do not push to apache next from your local master, or else you will
>>> >>push
>>> >> > all the changes.
>>> >> >
>>> >> > I agree, this is a little confusing, but after a few practice runs
>>>it
>>> >> > should be easy to figure out. You should probably also check what
>>> >>would
>>> >> be
>>> >> > pushed with 'git diff apache/[target-branch]' or tag on --stat to
>>> >>that to
>>> >> > just see that files that would signal a quick "uh-oh".
>>> >> >
>>> >> > I'll work to update the wiki later today, and likely others will
>>>have
>>> >> more
>>> >> > tips on how to make sure we don't make mistakes.
>>> >> >
>>> >> > -Michal
>>> >> >
>>> >> >
>>> >> >
>>> >> > On Wed, Feb 20, 2013 at 12:42 PM, Becky Gibson <
>>> gibson.becky@gmail.com
>>> >> > >wrote:
>>> >> >
>>> >> > > Can someone please provide a "git cordova release process for
>>> >>dummies"
>>> >> > > example to make sure I do the release commits and merges properly
>>> >>(the
>>> >> > > committerWorkflow example didn't help me as I didn't understand
>>>the
>>> >> > > topic_branch and to_be_merged distinction)
>>> >> > >
>>> >> > > At any rate, can I do a git checkout apache next into my "master"
>>> >> branch?
>>> >> > > Then I can checkout my working_branch, rebase master (which
>>> >>contains
>>> >> > the
>>> >> > > next code) checkout master, merge my fix and push apache next.
>>> >> > > git checkout apache next
>>> >> > > git checkout working_branch_with_fix
>>> >> > > git rebase master
>>> >> > > git checkout master
>>> >> > > git merge working_branch_with_fix
>>> >> > > git push apache next
>>> >> > >
>>> >> > > and then repeat this for apache master with the possibility of
>>> >>needing
>>> >> to
>>> >> > > use -ff when I merge. Am I on the right track?
>>> >> > >
>>> >> > > humbled by git,
>>> >> > > -becky
>>> >> > >
>>> >> > > On Fri, Feb 8, 2013 at 5:22 PM, Marcel Kinard
>>><cm...@gmail.com>
>>> >> > wrote:
>>> >> > >
>>> >> > > > Nice! Thanks, Andrew!
>>> >> > > >
>>> >> > > > -- Marcel Kinard
>>> >> > > >
>>> >> > > > On Feb 7, 2013, at 2:59 PM, Andrew Grieve
>>><ag...@chromium.org>
>>> >> > wrote:
>>> >> > > >
>>> >> > > > > The doc's not up-to-date, but I think we ended on consensus
>>>for
>>> >>the
>>> >> > > code
>>> >> > > > > version. I've taken a stab at updating the wiki pages:
>>> >> > > > >
>>> >> > > > > http://wiki.apache.org/cordova/CordovaAndGit -- Added the
>>>idea
>>> >>of
>>> >> > > > having
>>> >> > > > > both a master and a next branch
>>> >> > > > > http://wiki.apache.org/cordova/CommitterWorkflow -- Added
>>> >>Jesse's
>>> >> > > > version
>>> >> > > > > of the "which branch - in code"
>>> >> > > > > http://wiki.apache.org/cordova/CuttingReleases -- Changed
>>> >>tagging
>>> >> > > > > instructions to refer to the "next" branch
>>> >> > > > >
>>> >> > > > >
>>> >> > > > > On Thu, Feb 7, 2013 at 1:26 PM, Marcel Kinard
>>> >><cm...@gmail.com>
>>> >> > > > wrote:
>>> >> > > > >
>>> >> > > > >> With 2.5 starting, it appears time to poke this thread.
>>> >> > > > >>
>>> >> > > > >> - Is the Google doc refreshed with the latest consensus?
>>> >> > > > >> - If so, should the Google doc be transferred to a wiki
>>>page?
>>> >> > > > >> - Have the necessary branches been created?
>>> >> > > > >> - Are we all in the boat, and understand how to row this
>>>beast?
>>> >> > > > >>
>>> >> > > > >> -- Marcel Kinard
>>> >> > > > >>
>>> >> > > > >> On Jan 24, 2013, at 5:14 PM, Jesse <pu...@gmail.com>
>>> >> wrote:
>>> >> > > > >>
>>> >> > > > >>> Nice Shaz, but I was hoping it was a github style network
>>> >> > > visualization
>>> >> > > > >>> that included a few versions worth of merges.
>>> >> > > > >>> Who wants to draw that?
>>> >> > > > >>>
>>> >> > > > >>> On Thu, Jan 24, 2013 at 2:05 PM, Shazron
>>><sh...@gmail.com>
>>> >> > wrote:
>>> >> > > > >>>
>>> >> > > > >>>> Inline image got mangled, here it is linked:
>>> >>http://cl.ly/MOrD
>>> >> > > > >>>>
>>> >> > > > >>>>
>>> >> > > > >>>> On Thu, Jan 24, 2013 at 1:39 PM, Shazron
>>><sh...@gmail.com>
>>> >> > wrote:
>>> >> > > > >>>>
>>> >> > > > >>>>> Thanks for the pseudocode Andrew, seems simpler to
>>> >>understand
>>> >> ;)
>>> >> > > > >> Jesse's
>>> >> > > > >>>>> re-factor makes it even easier. Here's my contrib for
>>>those
>>> >> more
>>> >> > > > >> visually
>>> >> > > > >>>>> inclined:
>>> >> > > > >>>>>
>>> >> > > > >>>>>
>>> >> > > > >>>>> [image: Inline image 2]
>>> >> > > > >>>>>
>>> >> > > > >>>>>
>>> >> > > > >>>>> On Thu, Jan 24, 2013 at 1:29 PM, Andrew Grieve <
>>> >> > > agrieve@chromium.org
>>> >> > > > >>> wrote:
>>> >> > > > >>>>>
>>> >> > > > >>>>>> Nice! even simpler. :)
>>> >> > > > >>>>>>
>>> >> > > > >>>>>>
>>> >> > > > >>>>>> On Thu, Jan 24, 2013 at 3:44 PM, Jesse <
>>> >> purplecabbage@gmail.com
>>> >> > >
>>> >> > > > >> wrote:
>>> >> > > > >>>>>>
>>> >> > > > >>>>>>> Thanks for clarifying Andrew. et al, I guess I was
>>> >> > > > mis-understanding
>>> >> > > > >>>>>> some
>>> >> > > > >>>>>>> of the earlier discussion around naming stuff.
>>> >> > > > >>>>>>>
>>> >> > > > >>>>>>> So everything is going to master all the time, and we
>>>only
>>> >> care
>>> >> > > > about
>>> >> > > > >>>>>>> 'next' if we are inReleaseMode and it is a bug fix?
>>> >> > > > >>>>>>>
>>> >> > > > >>>>>>> if(inReleaseMode && isBugFix) {
>>> >> > > > >>>>>>> commitToBranch('next');
>>> >> > > > >>>>>>> mergeBranch('next').into('master');
>>> >> > > > >>>>>>> }
>>> >> > > > >>>>>>> else {
>>> >> > > > >>>>>>> commitToBranch('master');
>>> >> > > > >>>>>>> }
>>> >> > > > >>>>>>>
>>> >> > > > >>>>>>>
>>> >> > > > >>>>>>>
>>> >> > > > >>>>>>>
>>> >> > > > >>>>>>>
>>> >> > > > >>>>>>> On Thu, Jan 24, 2013 at 12:29 PM, Andrew Grieve <
>>> >> > > > >> agrieve@chromium.org
>>> >> > > > >>>>>>>> wrote:
>>> >> > > > >>>>>>>
>>> >> > > > >>>>>>>> Just to clarify - there should be *no* using of the
>>>git
>>> >> > > > >>>>>> cherry-picking
>>> >> > > > >>>>>>>> command, only git merge.
>>> >> > > > >>>>>>>>
>>> >> > > > >>>>>>>> Jesse - not sure what you're referring to with "branch
>>> >>must
>>> >> be
>>> >> > > > named
>>> >> > > > >>>>>> x".
>>> >> > > > >>>>>>>> The latest revision of the proposal has only two
>>> >>branches:
>>> >> > > master
>>> >> > > > >> and
>>> >> > > > >>>>>>> next.
>>> >> > > > >>>>>>>> Do you mean you don't like the name "next"?
>>> >> > > > >>>>>>>>
>>> >> > > > >>>>>>>> Maybe the proposal will seem simpler if put in the
>>>form
>>> >>of
>>> >> > code
>>> >> > > :)
>>> >> > > > >>>>>>>>
>>> >> > > > >>>>>>>> if (!inReleaseMode) {
>>> >> > > > >>>>>>>> commitToBranch('master');
>>> >> > > > >>>>>>>> } else {
>>> >> > > > >>>>>>>> if (isBugFix) {
>>> >> > > > >>>>>>>> commitToBranch('next');
>>> >> > > > >>>>>>>> mergeBranch('next').into('master');
>>> >> > > > >>>>>>>> } else {
>>> >> > > > >>>>>>>> commitToBranch('master');
>>> >> > > > >>>>>>>> }
>>> >> > > > >>>>>>>> }
>>> >> > > > >>>>>>>>
>>> >> > > > >>>>>>>>
>>> >> > > > >>>>>>>> On Thu, Jan 24, 2013 at 3:06 PM, Braden Shepherdson <
>>> >> > > > >>>>>> braden@chromium.org
>>> >> > > > >>>>>>>>> wrote:
>>> >> > > > >>>>>>>>
>>> >> > > > >>>>>>>>> Most of the time the flow will be unchanged: push to
>>> >> master.
>>> >> > > > >>>>>> Tagging
>>> >> > > > >>>>>>>> things
>>> >> > > > >>>>>>>>> we already know how to do; that doesn't change.
>>> >> > > > >>>>>>>>>
>>> >> > > > >>>>>>>>> The only new flow for most people is cherrypicking
>>>bug
>>> >> fixes
>>> >> > > from
>>> >> > > > >>>>>>> master
>>> >> > > > >>>>>>>> to
>>> >> > > > >>>>>>>>> next, which we can give examples of. Plus that could
>>> >>remain
>>> >> > the
>>> >> > > > >>>>>>>>> responsibility of the main platform maintainers, who
>>>are
>>> >> > doing
>>> >> > > > the
>>> >> > > > >>>>>>>> tagging.
>>> >> > > > >>>>>>>>>
>>> >> > > > >>>>>>>>> Braden
>>> >> > > > >>>>>>>>>
>>> >> > > > >>>>>>>>>
>>> >> > > > >>>>>>>>> On Thu, Jan 24, 2013 at 2:56 PM, Jesse <
>>> >> > > purplecabbage@gmail.com>
>>> >> > > > >>>>>>> wrote:
>>> >> > > > >>>>>>>>>
>>> >> > > > >>>>>>>>>> On Thu, Jan 24, 2013 at 11:09 AM, Braden
>>>Shepherdson <
>>> >> > > > >>>>>>>>> braden@chromium.org
>>> >> > > > >>>>>>>>>>> wrote:
>>> >> > > > >>>>>>>>>>
>>> >> > > > >>>>>>>>>>> The founding goal we're trying to accomplish here
>>>is
>>> >>that
>>> >> > we
>>> >> > > > >>>>>> don't
>>> >> > > > >>>>>>>> want
>>> >> > > > >>>>>>>>>>> everyone sitting on changes to be in the next
>>>version
>>> >> while
>>> >> > > we
>>> >> > > > >>>>>> use
>>> >> > > > >>>>>>>>> master
>>> >> > > > >>>>>>>>>>> to prep a release.
>>> >> > > > >>>>>>>>>>>
>>> >> > > > >>>>>>>>>>> I don't think having one branch for prepping the
>>> >>release
>>> >> > and
>>> >> > > > >>>>>>> another
>>> >> > > > >>>>>>>>> for
>>> >> > > > >>>>>>>>>>> main development is a lot of bureaucracy.
>>> >> > > > >>>>>>>>>>>
>>> >> > > > >>>>>>>>>>
>>> >> > > > >>>>>>>>>> It is not, the 'branch must be named x' is mainly
>>> >>where I
>>> >> > have
>>> >> > > > >>>>>>>> concerns.
>>> >> > > > >>>>>>>>>> Really I just want things simple.
>>> >> > > > >>>>>>>>>>
>>> >> > > > >>>>>>>>>>
>>> >> > > > >>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>
>>> >> > > > >>>>>>>>>>> On Thu, Jan 24, 2013 at 1:57 PM, Jesse MacFadyen <
>>> >> > > > >>>>>>>>>> purplecabbage@gmail.com
>>> >> > > > >>>>>>>>>>>> wrote:
>>> >> > > > >>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>> I have been quietly listening on this thread, but
>>> >> thought
>>> >> > I
>>> >> > > > >>>>>>> should
>>> >> > > > >>>>>>>> at
>>> >> > > > >>>>>>>>>>>> least share my opinion.
>>> >> > > > >>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>> I don't think adding contribution rules helps
>>>anyone.
>>> >> Git
>>> >> > is
>>> >> > > > >>>>>>>>>>>> complicated enough as it is, and this just all
>>>seems
>>> >> like
>>> >> > > > >>>>>>>>> bureaucracy.
>>> >> > > > >>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>> I think master should always contain the latest
>>> >>stable
>>> >> > code,
>>> >> > > > >>>>>> and
>>> >> > > > >>>>>>> be
>>> >> > > > >>>>>>>>>>>> periodically tagged with rc's and versions.
>>> >> > > > >>>>>>>>>>>> All work should be done in personal forks and
>>>feature
>>> >> > > > >>>>>> branches.
>>> >> > > > >>>>>>>>>>>> If the latest tag of master is an rc, then we
>>>should
>>> >> only
>>> >> > be
>>> >> > > > >>>>>>>> merging
>>> >> > > > >>>>>>>>>>>> bugfixes, until the release.
>>> >> > > > >>>>>>>>>>>> Immediately after tagging a version we decide
>>>which
>>> >> > feature
>>> >> > > > >>>>>>>> branches
>>> >> > > > >>>>>>>>>>>> and pull requests to pull in, and go for it.
>>> >> > > > >>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>> I don't think this is much different from what we
>>> >>have,
>>> >> > but
>>> >> > > I
>>> >> > > > >>>>>>> think
>>> >> > > > >>>>>>>>>>>> that is good.
>>> >> > > > >>>>>>>>>>>> The suggestions thus far, while interesting, don't
>>> >> > increase
>>> >> > > > >>>>>> our
>>> >> > > > >>>>>>>>>>>> velocity in my opinion. Also, I can also pretty
>>>much
>>> >> > > guaranty
>>> >> > > > >>>>>>> I'll
>>> >> > > > >>>>>>>>>>>> screw it up for the next 3-4 versions. ( because
>>>I'm
>>> >> dumb
>>> >> > )
>>> >> > > > >>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>> Cheers,
>>> >> > > > >>>>>>>>>>>> Jesse
>>> >> > > > >>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>> On 2013-01-24, at 5:53 AM, Andrew Grieve <
>>> >> > > > >>>>>> agrieve@chromium.org>
>>> >> > > > >>>>>>>>> wrote:
>>> >> > > > >>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>> On Wed, Jan 23, 2013 at 4:58 PM, Michael Brooks <
>>> >> > > > >>>>>>>>>>> michael@michaelbrooks.ca
>>> >> > > > >>>>>>>>>>>>> wrote:
>>> >> > > > >>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>> Before we move forward, I have a few questions
>>>about
>>> >> the
>>> >> > > > >>>>>> "no
>>> >> > > > >>>>>>>>> master"
>>> >> > > > >>>>>>>>>>>>> approach.
>>> >> > > > >>>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>> There is *no* master branch, so that
>>> >>community-driven
>>> >> > pull
>>> >> > > > >>>>>>>> requests
>>> >> > > > >>>>>>>>>>> will
>>> >> > > > >>>>>>>>>>>> be
>>> >> > > > >>>>>>>>>>>>>> forced to think about which branch to request
>>> >>against.
>>> >> > > > >>>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>> - Andrew, can you cite other projects that do not
>>> >>use a
>>> >> > > > >>>>>> master
>>> >> > > > >>>>>>>>>> branch?
>>> >> > > > >>>>>>>>>>>> This project is my first time using git / github,
>>>so
>>> >>I
>>> >> > don't
>>> >> > > > >>>>>> have
>>> >> > > > >>>>>>>>> much
>>> >> > > > >>>>>>>>>> to
>>> >> > > > >>>>>>>>>>>> draw from. I was going off of others' suggestions
>>>on
>>> >> this
>>> >> > > > >>>>>> thread
>>> >> > > > >>>>>>>>> when I
>>> >> > > > >>>>>>>>>>>> proposed the names.
>>> >> > > > >>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>> - On Github, you must have a default branch. If
>>>not
>>> >> > > > >>>>>> master, it
>>> >> > > > >>>>>>>> must
>>> >> > > > >>>>>>>>>> be
>>> >> > > > >>>>>>>>>>>>> something else. So, users are not forced to think
>>> >>about
>>> >> > the
>>> >> > > > >>>>>>>> branch
>>> >> > > > >>>>>>>>> to
>>> >> > > > >>>>>>>>>>>> send
>>> >> > > > >>>>>>>>>>>>> a pull request again... they will likely just use
>>> >>the
>>> >> > > > >>>>>> default.
>>> >> > > > >>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>> Hmm, good point. The goal is to get people
>>> >>downloading
>>> >> > > > >>>>>> Cordova
>>> >> > > > >>>>>>> for
>>> >> > > > >>>>>>>>> use
>>> >> > > > >>>>>>>>>> to
>>> >> > > > >>>>>>>>>>>> end up with Stable, and for developers to send
>>>pull
>>> >> > requests
>>> >> > > > >>>>>>>> against
>>> >> > > > >>>>>>>>>> dev.
>>> >> > > > >>>>>>>>>>>> With a forced default branch, I don't think we can
>>> >> > > accomplish
>>> >> > > > >>>>>>> this.
>>> >> > > > >>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>> - Why is the "stable" branch not just "master"?
>>> >> > > > >>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>> My thinking was that it's not obvious whether
>>>Master
>>> >>==
>>> >> > > > >>>>>> bleeding
>>> >> > > > >>>>>>>>> edge,
>>> >> > > > >>>>>>>>>> or
>>> >> > > > >>>>>>>>>>>> Master == Stable version. Using the names "dev"
>>>and
>>> >> > "stable"
>>> >> > > > >>>>>>> makes
>>> >> > > > >>>>>>>>> it a
>>> >> > > > >>>>>>>>>>> bit
>>> >> > > > >>>>>>>>>>>> clear.
>>> >> > > > >>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>> So... If github forces us to have a default
>>>branch,
>>> >>I'm
>>> >> > > > >>>>>> thinking
>>> >> > > > >>>>>>>> that
>>> >> > > > >>>>>>>>>>>> having users send pull requests against "dev" is
>>>more
>>> >> > > > >>>>>> valuable
>>> >> > > > >>>>>>> than
>>> >> > > > >>>>>>>>>>> having
>>> >> > > > >>>>>>>>>>>> people download the latest "stable" by default. If
>>> >> people
>>> >> > > are
>>> >> > > > >>>>>>>> pulling
>>> >> > > > >>>>>>>>>>> code
>>> >> > > > >>>>>>>>>>>> from github rather than from our release .zip
>>>files,
>>> >> then
>>> >> > > > >>>>>> it's
>>> >> > > > >>>>>>>> likely
>>> >> > > > >>>>>>>>>>> they
>>> >> > > > >>>>>>>>>>>> want to hack on it anyways, or that they want the
>>>dev
>>> >> > > > >>>>>> version to
>>> >> > > > >>>>>>>> see
>>> >> > > > >>>>>>>>> if
>>> >> > > > >>>>>>>>>>>> bugs are fixed.
>>> >> > > > >>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>> Soo.... Here's version #3! If anyone can think of
>>> >>how to
>>> >> > > > >>>>>> keep the
>>> >> > > > >>>>>>>>> three
>>> >> > > > >>>>>>>>>>>> branches while addressing being forced to have a
>>> >>default
>>> >> > > > >>>>>> branch,
>>> >> > > > >>>>>>>> feel
>>> >> > > > >>>>>>>>>>> free
>>> >> > > > >>>>>>>>>>>> to speak up! :)
>>> >> > > > >>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>> Cordova repositories have two main branches:
>>> >> > > > >>>>>>>>>>>> 1. master
>>> >> > > > >>>>>>>>>>>> 2. next
>>> >> > > > >>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>> Topic branches exist for collaborating on
>>>features,
>>> >>or
>>> >> for
>>> >> > > > >>>>>>>>> code-review
>>> >> > > > >>>>>>>>>>>> purposes.
>>> >> > > > >>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>> Cordova uses tags to label releases.
>>> >> > > > >>>>>>>>>>>> - Each release candidate has a tag. e.g.
>>>"2.2.0rc1"
>>> >> > > > >>>>>>>>>>>> - Each release has a tag. e.g. "2.2.0"
>>> >> > > > >>>>>>>>>>>> - The "latest" tag points to the last stable
>>>release
>>> >> (this
>>> >> > > > >>>>>>> follows
>>> >> > > > >>>>>>>>> npm
>>> >> > > > >>>>>>>>>>>> conventions)
>>> >> > > > >>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>> 1. The "next" branch.
>>> >> > > > >>>>>>>>>>>> - This branch is used only when in the process of
>>> >>doing
>>> >> a
>>> >> > > > >>>>>>> release.
>>> >> > > > >>>>>>>>>>>> - All tags are created from this branch.
>>> >> > > > >>>>>>>>>>>> - All release-candidate bug-fixes are done on this
>>> >> branch.
>>> >> > > > >>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>> 2. The "master" branch.
>>> >> > > > >>>>>>>>>>>> - When not in the release-process, all commits are
>>> >>made
>>> >> > here
>>> >> > > > >>>>>>>>>>>> - When in the release-process, all non-bugfix
>>>commits
>>> >> are
>>> >> > > > >>>>>> made
>>> >> > > > >>>>>>>> here
>>> >> > > > >>>>>>>>>>>> - This is where topic-branches are merged into.
>>> >> > > > >>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>> Cutting a release:
>>> >> > > > >>>>>>>>>>>> 1. git checkout next && git merge --ff-only master
>>> >> > > > >>>>>>>>>>>> 2. Test test test!
>>> >> > > > >>>>>>>>>>>> 3. Fix bugs by committing them directly to "next"
>>>and
>>> >> then
>>> >> > > > >>>>>> doing
>>> >> > > > >>>>>>> a
>>> >> > > > >>>>>>>>>> non-ff
>>> >> > > > >>>>>>>>>>>> merge of next into master
>>> >> > > > >>>>>>>>>>>> 4. Tag release candidate
>>> >> > > > >>>>>>>>>>>> 5. Repeat steps 2-4 as necessary
>>> >> > > > >>>>>>>>>>>> 6. Tag the release (both by version and by
>>>updating
>>> >>the
>>> >> > > > >>>>>> "latest"
>>> >> > > > >>>>>>>> tag)
>>> >> > > > >>>>>>>>>>>> 7. Create distribution .zip file
>>> >> > > > >>>>>>>>>>>> 8. Test one last time using the dist files
>>> >> > > > >>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>> Thanks,
>>> >> > > > >>>>>>>>>>>>> Michael
>>> >> > > > >>>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>> On Wed, Jan 23, 2013 at 11:25 AM, Brian LeRoux <
>>> >> > b@brian.io
>>> >> > > > >>>>>>>
>>> >> > > > >>>>>>>> wrote:
>>> >> > > > >>>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>>> I'm liking it. Start in 2.5?
>>> >> > > > >>>>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>>> On Wed, Jan 23, 2013 at 1:19 PM, Filip Maj <
>>> >> > fil@adobe.com
>>> >> > > > >>>>>>>
>>> >> > > > >>>>>>>> wrote:
>>> >> > > > >>>>>>>>>>>>>>> Looks great Andrew!
>>> >> > > > >>>>>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>>>> If everyone's on board, how are we going to
>>>test
>>> >>run
>>> >> > > > >>>>>> this?
>>> >> > > > >>>>>>>> Flip a
>>> >> > > > >>>>>>>>>>>>> switch
>>> >> > > > >>>>>>>>>>>>>>> at a certain point, give it a shot with one
>>>repo
>>> >>for
>>> >> > one
>>> >> > > > >>>>>> RC?
>>> >> > > > >>>>>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>>>> On 1/22/13 12:29 PM, "Andrew Grieve" <
>>> >> > > > >>>>>> agrieve@chromium.org>
>>> >> > > > >>>>>>>>> wrote:
>>> >> > > > >>>>>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>>>>> Braden, you're right. I've now done some local
>>> >> playing
>>> >> > > > >>>>>>> around
>>> >> > > > >>>>>>>> in
>>> >> > > > >>>>>>>>>>> git,
>>> >> > > > >>>>>>>>>>>>> and
>>> >> > > > >>>>>>>>>>>>>>>> have an updated proposal that uses merges
>>> >>instead of
>>> >> > > > >>>>>>> deleting
>>> >> > > > >>>>>>>>>>>> branches.
>>> >> > > > >>>>>>>>>>>>>>>> PTAL:
>>> >> > > > >>>>>>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>>>>> Cordova repositories have three main branches:
>>> >> > > > >>>>>>>>>>>>>>>> 1. stable
>>> >> > > > >>>>>>>>>>>>>>>> 2. next
>>> >> > > > >>>>>>>>>>>>>>>> 3. dev
>>> >> > > > >>>>>>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>>>>> Topic branches also exist for collaborating on
>>> >> > > > >>>>>> features, or
>>> >> > > > >>>>>>>> for
>>> >> > > > >>>>>>>>>>>>>>>> code-review
>>> >> > > > >>>>>>>>>>>>>>>> purposes.
>>> >> > > > >>>>>>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>>>>> There is *no* master branch, so that
>>> >> community-driven
>>> >> > > > >>>>>> pull
>>> >> > > > >>>>>>>>>> requests
>>> >> > > > >>>>>>>>>>>>> will
>>> >> > > > >>>>>>>>>>>>>>>> be
>>> >> > > > >>>>>>>>>>>>>>>> forced to think about which branch to request
>>> >> against.
>>> >> > > > >>>>>>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>>>>> 1. The "stable" branch.
>>> >> > > > >>>>>>>>>>>>>>>> - Sits at the latest stable release of cordova
>>> >> > > > >>>>>>>>>>>>>>>> - This changes only when doing fast-forward
>>> >>merges
>>> >> > from
>>> >> > > > >>>>>>> "next"
>>> >> > > > >>>>>>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>>>>> 2. The "next" branch.
>>> >> > > > >>>>>>>>>>>>>>>> - This branch is used only when in the
>>>process of
>>> >> > doing
>>> >> > > > >>>>>> a
>>> >> > > > >>>>>>>>> release.
>>> >> > > > >>>>>>>>>>>>>>>> - All tags (both stable and RC) are done on
>>>this
>>> >> > branch.
>>> >> > > > >>>>>>>>>>>>>>>> - All release-candidate bug-fixes are done on
>>> >>this
>>> >> > > > >>>>>> branch.
>>> >> > > > >>>>>>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>>>>> 3. The "dev" branch.
>>> >> > > > >>>>>>>>>>>>>>>> - This is where non-release-candidate commits
>>>are
>>> >> done
>>> >> > > > >>>>>>>>>>>>>>>> - This is where topic-branches are merged
>>>into.
>>> >> > > > >>>>>>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>>>>> Cutting a release:
>>> >> > > > >>>>>>>>>>>>>>>> 1. git checkout next && git merge --ff-only
>>>dev
>>> >> > > > >>>>>>>>>>>>>>>> 2. Test test test!
>>> >> > > > >>>>>>>>>>>>>>>> 3. Fix bugs by committing them directly to
>>>"next"
>>> >> and
>>> >> > > > >>>>>> then
>>> >> > > > >>>>>>>>> doing a
>>> >> > > > >>>>>>>>>>>>> non-ff
>>> >> > > > >>>>>>>>>>>>>>>> merge of next into dev
>>> >> > > > >>>>>>>>>>>>>>>> 4. Tag release candidate
>>> >> > > > >>>>>>>>>>>>>>>> 5. Repeat steps 2-4 as necessary
>>> >> > > > >>>>>>>>>>>>>>>> 6. Tag the release
>>> >> > > > >>>>>>>>>>>>>>>> 7. Create distribution .zip file
>>> >> > > > >>>>>>>>>>>>>>>> 8. Test one last time using the dist files
>>> >> > > > >>>>>>>>>>>>>>>> 9. git checkout stable && git merge --ff-only
>>> >>next
>>> >> > > > >>>>>>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>>>>> On Tue, Jan 22, 2013 at 1:59 PM, Braden
>>> >>Shepherdson
>>> >> > > > >>>>>>>>>>>>>>>> <br...@chromium.org>wrote:
>>> >> > > > >>>>>>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>>>>>> I think deleting and recreating branches with
>>> >>the
>>> >> > same
>>> >> > > > >>>>>> name
>>> >> > > > >>>>>>>> can
>>> >> > > > >>>>>>>>>>> cause
>>> >> > > > >>>>>>>>>>>>>>>>> badness in git[1] because of remotes. It's
>>>not
>>> >> really
>>> >> > > > >>>>>> the
>>> >> > > > >>>>>>>> same
>>> >> > > > >>>>>>>>>>> branch
>>> >> > > > >>>>>>>>>>>>>> in
>>> >> > > > >>>>>>>>>>>>>>>>> terms of commits, and git thinks that your
>>>old
>>> >> stable
>>> >> > > > >>>>>> and
>>> >> > > > >>>>>>> the
>>> >> > > > >>>>>>>>> new
>>> >> > > > >>>>>>>>>>>>>> stable
>>> >> > > > >>>>>>>>>>>>>>>>> differ by all of each of their commits. Tags
>>> >>can be
>>> >> > > > >>>>>> moved
>>> >> > > > >>>>>>>>>>>>> arbitrarily,
>>> >> > > > >>>>>>>>>>>>>>>>> so I
>>> >> > > > >>>>>>>>>>>>>>>>> think stable makes sense as a tag. I'm not
>>>sure
>>> >> about
>>> >> > > > >>>>>> how
>>> >> > > > >>>>>>>> best
>>> >> > > > >>>>>>>>> to
>>> >> > > > >>>>>>>>>>>>>> handle
>>> >> > > > >>>>>>>>>>>>>>>>> next.
>>> >> > > > >>>>>>>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>>>>>> [1]
>>> >> > > > >>>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>
>>> >> > > > >>>>>>>>>>
>>> >> > > > >>>>>>>>>
>>> >> > > > >>>>>>>>
>>> >> > > > >>>>>>>
>>> >> > > > >>>>>>
>>> >> > > > >>
>>> >> > > >
>>> >> > >
>>> >> >
>>> >>
>>> >>
>>>
>>>http://stackoverflow.com/questions/11844581/git-delete-and-recreate-branc
>>> >> > > > >>>>>>>>>>>>>>>>> h
>>> >> > > > >>>>>>>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>>>>>> On Tue, Jan 22, 2013 at 11:31 AM, Andrew
>>>Grieve
>>> >><
>>> >> > > > >>>>>>>>>>>>> agrieve@chromium.org
>>> >> > > > >>>>>>>>>>>>>>>>>> wrote:
>>> >> > > > >>>>>>>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>>>>>>> Michal's attending hackathons for the week,
>>>and
>>> >> I'm
>>> >> > > > >>>>>> not
>>> >> > > > >>>>>>> sure
>>> >> > > > >>>>>>>>> we
>>> >> > > > >>>>>>>>>>>>> need
>>> >> > > > >>>>>>>>>>>>>>>>> to
>>> >> > > > >>>>>>>>>>>>>>>>> do
>>> >> > > > >>>>>>>>>>>>>>>>>> a hang-out for this, as I think we really
>>>are
>>> >> quite
>>> >> > > > >>>>>> close
>>> >> > > > >>>>>>> to
>>> >> > > > >>>>>>>>>>>>>> resolving
>>> >> > > > >>>>>>>>>>>>>>>>>> this. I'd really like to resolve this ASAP
>>>so
>>> >>that
>>> >> > we
>>> >> > > > >>>>>>> don't
>>> >> > > > >>>>>>>>> need
>>> >> > > > >>>>>>>>>>> to
>>> >> > > > >>>>>>>>>>>>>>>>> have
>>> >> > > > >>>>>>>>>>>>>>>>> a
>>> >> > > > >>>>>>>>>>>>>>>>>> code-freeze for this release.
>>> >> > > > >>>>>>>>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>>>>>>> Here's a proposal:
>>> >> > > > >>>>>>>>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>>>>>>> Cordova repositories have three main
>>>branches:
>>> >> > > > >>>>>>>>>>>>>>>>>> 1. stable
>>> >> > > > >>>>>>>>>>>>>>>>>> 2. next
>>> >> > > > >>>>>>>>>>>>>>>>>> 3. dev
>>> >> > > > >>>>>>>>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>>>>>>> Topic branches also exist for collaborating
>>>on
>>> >> > > > >>>>>> features,
>>> >> > > > >>>>>>> or
>>> >> > > > >>>>>>>>> for
>>> >> > > > >>>>>>>>>>>>>>>>> code-review
>>> >> > > > >>>>>>>>>>>>>>>>>> purposes.
>>> >> > > > >>>>>>>>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>>>>>>> There is *no* master branch, so that
>>> >> > community-driven
>>> >> > > > >>>>>> pull
>>> >> > > > >>>>>>>>>>> requests
>>> >> > > > >>>>>>>>>>>>>>>>> will
>>> >> > > > >>>>>>>>>>>>>>>>> be
>>> >> > > > >>>>>>>>>>>>>>>>>> forced to think about which branch to
>>>request
>>> >> > against.
>>> >> > > > >>>>>>>>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>>>>>>> 1. The "stable" branch.
>>> >> > > > >>>>>>>>>>>>>>>>>> - Sits at the latest stable release of
>>>cordova
>>> >> > > > >>>>>>>>>>>>>>>>>> - No one ever commits to the "stable"
>>>branch.
>>> >>It
>>> >> > > > >>>>>> exists
>>> >> > > > >>>>>>> only
>>> >> > > > >>>>>>>>> as
>>> >> > > > >>>>>>>>>> a
>>> >> > > > >>>>>>>>>>>>>>>>>> short-cut for checking out the latest stable
>>> >>tag.
>>> >> > > > >>>>>>>>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>>>>>>> 2. The "next" branch.
>>> >> > > > >>>>>>>>>>>>>>>>>> - This branch exists only when in the
>>>process
>>> >>of
>>> >> > > > >>>>>> doing a
>>> >> > > > >>>>>>>>>> release.
>>> >> > > > >>>>>>>>>>>>>>>>>> - All tags (both stable and RC) are done on
>>> >>this
>>> >> > > > >>>>>> branch.
>>> >> > > > >>>>>>>>>>>>>>>>>> - When a stable tag is done:
>>> >> > > > >>>>>>>>>>>>>>>>>> - The existing "stable" branch is deleted
>>> >> > > > >>>>>>>>>>>>>>>>>> - A new "stable" branch is created from
>>> >>"next".
>>> >> > > > >>>>>>>>>>>>>>>>>> - The "next" branch is deleted.
>>> >> > > > >>>>>>>>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>>>>>>> 3. The "dev" branch.
>>> >> > > > >>>>>>>>>>>>>>>>>> - This is where all commits are done
>>> >> > > > >>>>>>>>>>>>>>>>>> - This is where topic-branches are merged
>>>into.
>>> >> > > > >>>>>>>>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>>>>>>> Cutting a release:
>>> >> > > > >>>>>>>>>>>>>>>>>> 1. Create "next" from the HEAD of "dev"
>>> >> > > > >>>>>>>>>>>>>>>>>> 2. Test test test!
>>> >> > > > >>>>>>>>>>>>>>>>>> 3. Fix bugs by committing them to "dev" and
>>> >>then
>>> >> > > > >>>>>>>>> cherry-picking
>>> >> > > > >>>>>>>>>>>>> them
>>> >> > > > >>>>>>>>>>>>>>>>> into
>>> >> > > > >>>>>>>>>>>>>>>>>> "next"
>>> >> > > > >>>>>>>>>>>>>>>>>> 4. Tag release candidate
>>> >> > > > >>>>>>>>>>>>>>>>>> 5. Repeat steps 2-4 as necessary
>>> >> > > > >>>>>>>>>>>>>>>>>> 6. Tag the release
>>> >> > > > >>>>>>>>>>>>>>>>>> 7. Create distribution .zip file
>>> >> > > > >>>>>>>>>>>>>>>>>> 8. Test one last time using the dist files
>>> >> > > > >>>>>>>>>>>>>>>>>> 9. Delete "stable"
>>> >> > > > >>>>>>>>>>>>>>>>>> 10. Create a new "stable" by branching from
>>>the
>>> >> HEAD
>>> >> > > > >>>>>> of
>>> >> > > > >>>>>>>> "next"
>>> >> > > > >>>>>>>>>>>>>>>>>> 11. Delete the "next" branch
>>> >> > > > >>>>>>>>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>>>>>>> On Wed, Jan 16, 2013 at 10:34 AM, Michal
>>>Mocny
>>> >><
>>> >> > > > >>>>>>>>>>>>> mmocny@chromium.org>
>>> >> > > > >>>>>>>>>>>>>>>>>> wrote:
>>> >> > > > >>>>>>>>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>>>>>>>> Just going to throw out one of my personal
>>> >> > > > >>>>>> requirements
>>> >> > > > >>>>>>> for
>>> >> > > > >>>>>>>>>>>>>> whatever
>>> >> > > > >>>>>>>>>>>>>>>>>>> proposal we come up with, so it doesn't get
>>> >>lost:
>>> >> > > > >>>>>>>>>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>>>>>>>> * Feature branches are great for feature
>>>work
>>> >> > and/or
>>> >> > > > >>>>>>> large
>>> >> > > > >>>>>>>>>>>>> sweeping
>>> >> > > > >>>>>>>>>>>>>>>>>>> changes, as are JIRA bugs for tracking
>>>them,
>>> >>but
>>> >> > > > >>>>>> cordova
>>> >> > > > >>>>>>>> has
>>> >> > > > >>>>>>>>>> many
>>> >> > > > >>>>>>>>>>>>>>>>> many
>>> >> > > > >>>>>>>>>>>>>>>>>>> trivial issues that could be fixed with
>>> >> "drive-by"
>>> >> > > > >>>>>>> patches
>>> >> > > > >>>>>>>>> that
>>> >> > > > >>>>>>>>>>>>>>>>> require
>>> >> > > > >>>>>>>>>>>>>>>>>> as
>>> >> > > > >>>>>>>>>>>>>>>>>>> little friction to commit as possible.
>>> >> > > > >>>>>>>>>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>>>>>>>> On Tue, Jan 15, 2013 at 3:05 PM, Marcel
>>> >>Kinard <
>>> >> > > > >>>>>>>>>>>>> cmarcelk@gmail.com
>>> >> > > > >>>>>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>>>>>>> wrote:
>>> >> > > > >>>>>>>>>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>>>>>>>>> How about if there is a specific straw man
>>> >> > proposal
>>> >> > > > >>>>>> at
>>> >> > > > >>>>>>> the
>>> >> > > > >>>>>>>>>>>>>>>>> beginning
>>> >> > > > >>>>>>>>>>>>>>>>> of
>>> >> > > > >>>>>>>>>>>>>>>>>>>> the face-time? Then the folks that are in
>>> >> > agreement
>>> >> > > > >>>>>>> won't
>>> >> > > > >>>>>>>>> need
>>> >> > > > >>>>>>>>>>>>> to
>>> >> > > > >>>>>>>>>>>>>>>>> say
>>> >> > > > >>>>>>>>>>>>>>>>>>>> anything ;-)
>>> >> > > > >>>>>>>>>>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>>>>>>>>> Seriously, making adjustments to something
>>> >> > tangible
>>> >> > > > >>>>>> is
>>> >> > > > >>>>>>>>> easier
>>> >> > > > >>>>>>>>>>>>>> than
>>> >> > > > >>>>>>>>>>>>>>>>>>>> instantiating it from scratch. A volunteer
>>> >>for a
>>> >> > > > >>>>>> very
>>> >> > > > >>>>>>>> simple
>>> >> > > > >>>>>>>>>>>>>>>>> writeup
>>> >> > > > >>>>>>>>>>>>>>>>> on
>>> >> > > > >>>>>>>>>>>>>>>>>>> the
>>> >> > > > >>>>>>>>>>>>>>>>>>>> wiki?
>>> >> > > > >>>>>>>>>>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>>>>>>>>> -- Marcel Kinard
>>> >> > > > >>>>>>>>>>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>>>>>>>>> On 1/14/2013 10:06 PM, Michal Mocny wrote:
>>> >> > > > >>>>>>>>>>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>>>>>>>>>> Okay gentlemen, I think there have been
>>> >> countless
>>> >> > > > >>>>>> good
>>> >> > > > >>>>>>>>> points
>>> >> > > > >>>>>>>>>>>>>>>>> made
>>> >> > > > >>>>>>>>>>>>>>>>>> from
>>> >> > > > >>>>>>>>>>>>>>>>>>>>> all
>>> >> > > > >>>>>>>>>>>>>>>>>>>>> parties, but also some bike-shedding.
>>> >> > > > >>>>>>>>>>>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>>>>>>>>>> Perhaps it is time to schedule some
>>> >>face-time
>>> >> to
>>> >> > > > >>>>>> better
>>> >> > > > >>>>>>>>>>>>>>>>> articulate
>>> >> > > > >>>>>>>>>>>>>>>>>> some
>>> >> > > > >>>>>>>>>>>>>>>>>>> of
>>> >> > > > >>>>>>>>>>>>>>>>>>>>> the finer points, and to help come to
>>>some
>>> >> > > > >>>>>> consensus?
>>> >> > > > >>>>>>>>>>>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>>>>>>>>>> -Michal
>>> >> > > > >>>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>
>>> >> > > > >>>>>>>>>>
>>> >> > > > >>>>>>>>>>
>>> >> > > > >>>>>>>>>>
>>> >> > > > >>>>>>>>>> --
>>> >> > > > >>>>>>>>>> @purplecabbage
>>> >> > > > >>>>>>>>>> risingj.com
>>> >> > > > >>>>>>>>>>
>>> >> > > > >>>>>>>>>
>>> >> > > > >>>>>>>>
>>> >> > > > >>>>>>>
>>> >> > > > >>>>>>>
>>> >> > > > >>>>>>>
>>> >> > > > >>>>>>> --
>>> >> > > > >>>>>>> @purplecabbage
>>> >> > > > >>>>>>> risingj.com
>>> >> > > > >>>>>>>
>>> >> > > > >>>>>>
>>> >> > > > >>>>>
>>> >> > > > >>>>>
>>> >> > > > >>>>
>>> >> > > > >>>
>>> >> > > > >>>
>>> >> > > > >>> --
>>> >> > > > >>> @purplecabbage
>>> >> > > > >>> risingj.com
>>> >> > > > >>
>>> >> > > > >>
>>> >> > > >
>>> >> > > >
>>> >> > >
>>> >> >
>>> >>
>>>
>>>
>
Re: too long to package a release?
Posted by Filip Maj <fi...@adobe.com>.
Ok so the flow is: if you are committing into next, always merge into
master. Good. So the CI setup doesn't need to differentiate between master
and next. It can always pull from master.
On 2/20/13 11:04 AM, "Andrew Grieve" <ag...@chromium.org> wrote:
>Step 5 here: http://wiki.apache.org/cordova/CommitterWorkflow
>
>Probably it should be "isFixingRegression" instead of "isBugFix". I'll
>update it now.
>
>
>On Wed, Feb 20, 2013 at 1:59 PM, Filip Maj <fi...@adobe.com> wrote:
>
>> I noticed on iOS the commits going into next are mirrored on master.
>>
>> For Android that was not done.
>>
>> What is the correct process?
>>
>> On 2/20/13 10:12 AM, "Michal Mocny" <mm...@chromium.org> wrote:
>>
>> >oooo I didn't know that. Thanks!
>> >
>> >
>> >On Wed, Feb 20, 2013 at 1:10 PM, Becky Gibson
>> ><gi...@gmail.com>wrote:
>> >
>> >> Thank you, Michael! I do usually go a git push --dry-run to check
>>that
>> >>I
>> >> am pushing what I expect but I'll try the diff as well.
>> >>
>> >>
>> >> On Wed, Feb 20, 2013 at 1:07 PM, Michal Mocny <mm...@chromium.org>
>> >>wrote:
>> >>
>> >> > So there is also http://wiki.apache.org/cordova/CuttingReleases
>>which
>> >> may
>> >> > be useful (esp Taggin section).
>> >> >
>> >> > As far as the confusion with the two branch names: "topic_branch"
>>is
>> >>your
>> >> > local working branch for a bugfix/feature, and "to_be_merged" is
>> >>really
>> >> > "temporary_new_name_for_a_branch_to_do_rebase_in". I usually skip
>> >>that
>> >> > step and take the risk or rebasing in topic_branch (aside: this may
>> >> > negatively affect diffs if you push updates for a
>> >>review-edit-re-review
>> >> > cycle -- but this isn't an issue for cordova).
>> >> >
>> >> > Do not checkout 'next' into your master branch. Update your local
>> >> branches
>> >> > to include the remote next branch (with 'git pull apache' with no
>> >>branch)
>> >> > then you can switch to the next branch locally, apply your patch
>> >>there,
>> >> and
>> >> > push to that remote branch directly. Later, merge that commit into
>> >> master
>> >> > locally, and push that.
>> >> >
>> >> > Do not push to apache next from your local master, or else you will
>> >>push
>> >> > all the changes.
>> >> >
>> >> > I agree, this is a little confusing, but after a few practice runs
>>it
>> >> > should be easy to figure out. You should probably also check what
>> >>would
>> >> be
>> >> > pushed with 'git diff apache/[target-branch]' or tag on --stat to
>> >>that to
>> >> > just see that files that would signal a quick "uh-oh".
>> >> >
>> >> > I'll work to update the wiki later today, and likely others will
>>have
>> >> more
>> >> > tips on how to make sure we don't make mistakes.
>> >> >
>> >> > -Michal
>> >> >
>> >> >
>> >> >
>> >> > On Wed, Feb 20, 2013 at 12:42 PM, Becky Gibson <
>> gibson.becky@gmail.com
>> >> > >wrote:
>> >> >
>> >> > > Can someone please provide a "git cordova release process for
>> >>dummies"
>> >> > > example to make sure I do the release commits and merges properly
>> >>(the
>> >> > > committerWorkflow example didn't help me as I didn't understand
>>the
>> >> > > topic_branch and to_be_merged distinction)
>> >> > >
>> >> > > At any rate, can I do a git checkout apache next into my "master"
>> >> branch?
>> >> > > Then I can checkout my working_branch, rebase master (which
>> >>contains
>> >> > the
>> >> > > next code) checkout master, merge my fix and push apache next.
>> >> > > git checkout apache next
>> >> > > git checkout working_branch_with_fix
>> >> > > git rebase master
>> >> > > git checkout master
>> >> > > git merge working_branch_with_fix
>> >> > > git push apache next
>> >> > >
>> >> > > and then repeat this for apache master with the possibility of
>> >>needing
>> >> to
>> >> > > use -ff when I merge. Am I on the right track?
>> >> > >
>> >> > > humbled by git,
>> >> > > -becky
>> >> > >
>> >> > > On Fri, Feb 8, 2013 at 5:22 PM, Marcel Kinard
>><cm...@gmail.com>
>> >> > wrote:
>> >> > >
>> >> > > > Nice! Thanks, Andrew!
>> >> > > >
>> >> > > > -- Marcel Kinard
>> >> > > >
>> >> > > > On Feb 7, 2013, at 2:59 PM, Andrew Grieve
>><ag...@chromium.org>
>> >> > wrote:
>> >> > > >
>> >> > > > > The doc's not up-to-date, but I think we ended on consensus
>>for
>> >>the
>> >> > > code
>> >> > > > > version. I've taken a stab at updating the wiki pages:
>> >> > > > >
>> >> > > > > http://wiki.apache.org/cordova/CordovaAndGit -- Added the
>>idea
>> >>of
>> >> > > > having
>> >> > > > > both a master and a next branch
>> >> > > > > http://wiki.apache.org/cordova/CommitterWorkflow -- Added
>> >>Jesse's
>> >> > > > version
>> >> > > > > of the "which branch - in code"
>> >> > > > > http://wiki.apache.org/cordova/CuttingReleases -- Changed
>> >>tagging
>> >> > > > > instructions to refer to the "next" branch
>> >> > > > >
>> >> > > > >
>> >> > > > > On Thu, Feb 7, 2013 at 1:26 PM, Marcel Kinard
>> >><cm...@gmail.com>
>> >> > > > wrote:
>> >> > > > >
>> >> > > > >> With 2.5 starting, it appears time to poke this thread.
>> >> > > > >>
>> >> > > > >> - Is the Google doc refreshed with the latest consensus?
>> >> > > > >> - If so, should the Google doc be transferred to a wiki
>>page?
>> >> > > > >> - Have the necessary branches been created?
>> >> > > > >> - Are we all in the boat, and understand how to row this
>>beast?
>> >> > > > >>
>> >> > > > >> -- Marcel Kinard
>> >> > > > >>
>> >> > > > >> On Jan 24, 2013, at 5:14 PM, Jesse <pu...@gmail.com>
>> >> wrote:
>> >> > > > >>
>> >> > > > >>> Nice Shaz, but I was hoping it was a github style network
>> >> > > visualization
>> >> > > > >>> that included a few versions worth of merges.
>> >> > > > >>> Who wants to draw that?
>> >> > > > >>>
>> >> > > > >>> On Thu, Jan 24, 2013 at 2:05 PM, Shazron
>><sh...@gmail.com>
>> >> > wrote:
>> >> > > > >>>
>> >> > > > >>>> Inline image got mangled, here it is linked:
>> >>http://cl.ly/MOrD
>> >> > > > >>>>
>> >> > > > >>>>
>> >> > > > >>>> On Thu, Jan 24, 2013 at 1:39 PM, Shazron
>><sh...@gmail.com>
>> >> > wrote:
>> >> > > > >>>>
>> >> > > > >>>>> Thanks for the pseudocode Andrew, seems simpler to
>> >>understand
>> >> ;)
>> >> > > > >> Jesse's
>> >> > > > >>>>> re-factor makes it even easier. Here's my contrib for
>>those
>> >> more
>> >> > > > >> visually
>> >> > > > >>>>> inclined:
>> >> > > > >>>>>
>> >> > > > >>>>>
>> >> > > > >>>>> [image: Inline image 2]
>> >> > > > >>>>>
>> >> > > > >>>>>
>> >> > > > >>>>> On Thu, Jan 24, 2013 at 1:29 PM, Andrew Grieve <
>> >> > > agrieve@chromium.org
>> >> > > > >>> wrote:
>> >> > > > >>>>>
>> >> > > > >>>>>> Nice! even simpler. :)
>> >> > > > >>>>>>
>> >> > > > >>>>>>
>> >> > > > >>>>>> On Thu, Jan 24, 2013 at 3:44 PM, Jesse <
>> >> purplecabbage@gmail.com
>> >> > >
>> >> > > > >> wrote:
>> >> > > > >>>>>>
>> >> > > > >>>>>>> Thanks for clarifying Andrew. et al, I guess I was
>> >> > > > mis-understanding
>> >> > > > >>>>>> some
>> >> > > > >>>>>>> of the earlier discussion around naming stuff.
>> >> > > > >>>>>>>
>> >> > > > >>>>>>> So everything is going to master all the time, and we
>>only
>> >> care
>> >> > > > about
>> >> > > > >>>>>>> 'next' if we are inReleaseMode and it is a bug fix?
>> >> > > > >>>>>>>
>> >> > > > >>>>>>> if(inReleaseMode && isBugFix) {
>> >> > > > >>>>>>> commitToBranch('next');
>> >> > > > >>>>>>> mergeBranch('next').into('master');
>> >> > > > >>>>>>> }
>> >> > > > >>>>>>> else {
>> >> > > > >>>>>>> commitToBranch('master');
>> >> > > > >>>>>>> }
>> >> > > > >>>>>>>
>> >> > > > >>>>>>>
>> >> > > > >>>>>>>
>> >> > > > >>>>>>>
>> >> > > > >>>>>>>
>> >> > > > >>>>>>> On Thu, Jan 24, 2013 at 12:29 PM, Andrew Grieve <
>> >> > > > >> agrieve@chromium.org
>> >> > > > >>>>>>>> wrote:
>> >> > > > >>>>>>>
>> >> > > > >>>>>>>> Just to clarify - there should be *no* using of the
>>git
>> >> > > > >>>>>> cherry-picking
>> >> > > > >>>>>>>> command, only git merge.
>> >> > > > >>>>>>>>
>> >> > > > >>>>>>>> Jesse - not sure what you're referring to with "branch
>> >>must
>> >> be
>> >> > > > named
>> >> > > > >>>>>> x".
>> >> > > > >>>>>>>> The latest revision of the proposal has only two
>> >>branches:
>> >> > > master
>> >> > > > >> and
>> >> > > > >>>>>>> next.
>> >> > > > >>>>>>>> Do you mean you don't like the name "next"?
>> >> > > > >>>>>>>>
>> >> > > > >>>>>>>> Maybe the proposal will seem simpler if put in the
>>form
>> >>of
>> >> > code
>> >> > > :)
>> >> > > > >>>>>>>>
>> >> > > > >>>>>>>> if (!inReleaseMode) {
>> >> > > > >>>>>>>> commitToBranch('master');
>> >> > > > >>>>>>>> } else {
>> >> > > > >>>>>>>> if (isBugFix) {
>> >> > > > >>>>>>>> commitToBranch('next');
>> >> > > > >>>>>>>> mergeBranch('next').into('master');
>> >> > > > >>>>>>>> } else {
>> >> > > > >>>>>>>> commitToBranch('master');
>> >> > > > >>>>>>>> }
>> >> > > > >>>>>>>> }
>> >> > > > >>>>>>>>
>> >> > > > >>>>>>>>
>> >> > > > >>>>>>>> On Thu, Jan 24, 2013 at 3:06 PM, Braden Shepherdson <
>> >> > > > >>>>>> braden@chromium.org
>> >> > > > >>>>>>>>> wrote:
>> >> > > > >>>>>>>>
>> >> > > > >>>>>>>>> Most of the time the flow will be unchanged: push to
>> >> master.
>> >> > > > >>>>>> Tagging
>> >> > > > >>>>>>>> things
>> >> > > > >>>>>>>>> we already know how to do; that doesn't change.
>> >> > > > >>>>>>>>>
>> >> > > > >>>>>>>>> The only new flow for most people is cherrypicking
>>bug
>> >> fixes
>> >> > > from
>> >> > > > >>>>>>> master
>> >> > > > >>>>>>>> to
>> >> > > > >>>>>>>>> next, which we can give examples of. Plus that could
>> >>remain
>> >> > the
>> >> > > > >>>>>>>>> responsibility of the main platform maintainers, who
>>are
>> >> > doing
>> >> > > > the
>> >> > > > >>>>>>>> tagging.
>> >> > > > >>>>>>>>>
>> >> > > > >>>>>>>>> Braden
>> >> > > > >>>>>>>>>
>> >> > > > >>>>>>>>>
>> >> > > > >>>>>>>>> On Thu, Jan 24, 2013 at 2:56 PM, Jesse <
>> >> > > purplecabbage@gmail.com>
>> >> > > > >>>>>>> wrote:
>> >> > > > >>>>>>>>>
>> >> > > > >>>>>>>>>> On Thu, Jan 24, 2013 at 11:09 AM, Braden
>>Shepherdson <
>> >> > > > >>>>>>>>> braden@chromium.org
>> >> > > > >>>>>>>>>>> wrote:
>> >> > > > >>>>>>>>>>
>> >> > > > >>>>>>>>>>> The founding goal we're trying to accomplish here
>>is
>> >>that
>> >> > we
>> >> > > > >>>>>> don't
>> >> > > > >>>>>>>> want
>> >> > > > >>>>>>>>>>> everyone sitting on changes to be in the next
>>version
>> >> while
>> >> > > we
>> >> > > > >>>>>> use
>> >> > > > >>>>>>>>> master
>> >> > > > >>>>>>>>>>> to prep a release.
>> >> > > > >>>>>>>>>>>
>> >> > > > >>>>>>>>>>> I don't think having one branch for prepping the
>> >>release
>> >> > and
>> >> > > > >>>>>>> another
>> >> > > > >>>>>>>>> for
>> >> > > > >>>>>>>>>>> main development is a lot of bureaucracy.
>> >> > > > >>>>>>>>>>>
>> >> > > > >>>>>>>>>>
>> >> > > > >>>>>>>>>> It is not, the 'branch must be named x' is mainly
>> >>where I
>> >> > have
>> >> > > > >>>>>>>> concerns.
>> >> > > > >>>>>>>>>> Really I just want things simple.
>> >> > > > >>>>>>>>>>
>> >> > > > >>>>>>>>>>
>> >> > > > >>>>>>>>>>>
>> >> > > > >>>>>>>>>>>
>> >> > > > >>>>>>>>>>> On Thu, Jan 24, 2013 at 1:57 PM, Jesse MacFadyen <
>> >> > > > >>>>>>>>>> purplecabbage@gmail.com
>> >> > > > >>>>>>>>>>>> wrote:
>> >> > > > >>>>>>>>>>>
>> >> > > > >>>>>>>>>>>> I have been quietly listening on this thread, but
>> >> thought
>> >> > I
>> >> > > > >>>>>>> should
>> >> > > > >>>>>>>> at
>> >> > > > >>>>>>>>>>>> least share my opinion.
>> >> > > > >>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>> I don't think adding contribution rules helps
>>anyone.
>> >> Git
>> >> > is
>> >> > > > >>>>>>>>>>>> complicated enough as it is, and this just all
>>seems
>> >> like
>> >> > > > >>>>>>>>> bureaucracy.
>> >> > > > >>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>> I think master should always contain the latest
>> >>stable
>> >> > code,
>> >> > > > >>>>>> and
>> >> > > > >>>>>>> be
>> >> > > > >>>>>>>>>>>> periodically tagged with rc's and versions.
>> >> > > > >>>>>>>>>>>> All work should be done in personal forks and
>>feature
>> >> > > > >>>>>> branches.
>> >> > > > >>>>>>>>>>>> If the latest tag of master is an rc, then we
>>should
>> >> only
>> >> > be
>> >> > > > >>>>>>>> merging
>> >> > > > >>>>>>>>>>>> bugfixes, until the release.
>> >> > > > >>>>>>>>>>>> Immediately after tagging a version we decide
>>which
>> >> > feature
>> >> > > > >>>>>>>> branches
>> >> > > > >>>>>>>>>>>> and pull requests to pull in, and go for it.
>> >> > > > >>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>> I don't think this is much different from what we
>> >>have,
>> >> > but
>> >> > > I
>> >> > > > >>>>>>> think
>> >> > > > >>>>>>>>>>>> that is good.
>> >> > > > >>>>>>>>>>>> The suggestions thus far, while interesting, don't
>> >> > increase
>> >> > > > >>>>>> our
>> >> > > > >>>>>>>>>>>> velocity in my opinion. Also, I can also pretty
>>much
>> >> > > guaranty
>> >> > > > >>>>>>> I'll
>> >> > > > >>>>>>>>>>>> screw it up for the next 3-4 versions. ( because
>>I'm
>> >> dumb
>> >> > )
>> >> > > > >>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>> Cheers,
>> >> > > > >>>>>>>>>>>> Jesse
>> >> > > > >>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>> On 2013-01-24, at 5:53 AM, Andrew Grieve <
>> >> > > > >>>>>> agrieve@chromium.org>
>> >> > > > >>>>>>>>> wrote:
>> >> > > > >>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>> On Wed, Jan 23, 2013 at 4:58 PM, Michael Brooks <
>> >> > > > >>>>>>>>>>> michael@michaelbrooks.ca
>> >> > > > >>>>>>>>>>>>> wrote:
>> >> > > > >>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>> Before we move forward, I have a few questions
>>about
>> >> the
>> >> > > > >>>>>> "no
>> >> > > > >>>>>>>>> master"
>> >> > > > >>>>>>>>>>>>> approach.
>> >> > > > >>>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>> There is *no* master branch, so that
>> >>community-driven
>> >> > pull
>> >> > > > >>>>>>>> requests
>> >> > > > >>>>>>>>>>> will
>> >> > > > >>>>>>>>>>>> be
>> >> > > > >>>>>>>>>>>>>> forced to think about which branch to request
>> >>against.
>> >> > > > >>>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>> - Andrew, can you cite other projects that do not
>> >>use a
>> >> > > > >>>>>> master
>> >> > > > >>>>>>>>>> branch?
>> >> > > > >>>>>>>>>>>> This project is my first time using git / github,
>>so
>> >>I
>> >> > don't
>> >> > > > >>>>>> have
>> >> > > > >>>>>>>>> much
>> >> > > > >>>>>>>>>> to
>> >> > > > >>>>>>>>>>>> draw from. I was going off of others' suggestions
>>on
>> >> this
>> >> > > > >>>>>> thread
>> >> > > > >>>>>>>>> when I
>> >> > > > >>>>>>>>>>>> proposed the names.
>> >> > > > >>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>> - On Github, you must have a default branch. If
>>not
>> >> > > > >>>>>> master, it
>> >> > > > >>>>>>>> must
>> >> > > > >>>>>>>>>> be
>> >> > > > >>>>>>>>>>>>> something else. So, users are not forced to think
>> >>about
>> >> > the
>> >> > > > >>>>>>>> branch
>> >> > > > >>>>>>>>> to
>> >> > > > >>>>>>>>>>>> send
>> >> > > > >>>>>>>>>>>>> a pull request again... they will likely just use
>> >>the
>> >> > > > >>>>>> default.
>> >> > > > >>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>> Hmm, good point. The goal is to get people
>> >>downloading
>> >> > > > >>>>>> Cordova
>> >> > > > >>>>>>> for
>> >> > > > >>>>>>>>> use
>> >> > > > >>>>>>>>>> to
>> >> > > > >>>>>>>>>>>> end up with Stable, and for developers to send
>>pull
>> >> > requests
>> >> > > > >>>>>>>> against
>> >> > > > >>>>>>>>>> dev.
>> >> > > > >>>>>>>>>>>> With a forced default branch, I don't think we can
>> >> > > accomplish
>> >> > > > >>>>>>> this.
>> >> > > > >>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>> - Why is the "stable" branch not just "master"?
>> >> > > > >>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>> My thinking was that it's not obvious whether
>>Master
>> >>==
>> >> > > > >>>>>> bleeding
>> >> > > > >>>>>>>>> edge,
>> >> > > > >>>>>>>>>> or
>> >> > > > >>>>>>>>>>>> Master == Stable version. Using the names "dev"
>>and
>> >> > "stable"
>> >> > > > >>>>>>> makes
>> >> > > > >>>>>>>>> it a
>> >> > > > >>>>>>>>>>> bit
>> >> > > > >>>>>>>>>>>> clear.
>> >> > > > >>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>> So... If github forces us to have a default
>>branch,
>> >>I'm
>> >> > > > >>>>>> thinking
>> >> > > > >>>>>>>> that
>> >> > > > >>>>>>>>>>>> having users send pull requests against "dev" is
>>more
>> >> > > > >>>>>> valuable
>> >> > > > >>>>>>> than
>> >> > > > >>>>>>>>>>> having
>> >> > > > >>>>>>>>>>>> people download the latest "stable" by default. If
>> >> people
>> >> > > are
>> >> > > > >>>>>>>> pulling
>> >> > > > >>>>>>>>>>> code
>> >> > > > >>>>>>>>>>>> from github rather than from our release .zip
>>files,
>> >> then
>> >> > > > >>>>>> it's
>> >> > > > >>>>>>>> likely
>> >> > > > >>>>>>>>>>> they
>> >> > > > >>>>>>>>>>>> want to hack on it anyways, or that they want the
>>dev
>> >> > > > >>>>>> version to
>> >> > > > >>>>>>>> see
>> >> > > > >>>>>>>>> if
>> >> > > > >>>>>>>>>>>> bugs are fixed.
>> >> > > > >>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>> Soo.... Here's version #3! If anyone can think of
>> >>how to
>> >> > > > >>>>>> keep the
>> >> > > > >>>>>>>>> three
>> >> > > > >>>>>>>>>>>> branches while addressing being forced to have a
>> >>default
>> >> > > > >>>>>> branch,
>> >> > > > >>>>>>>> feel
>> >> > > > >>>>>>>>>>> free
>> >> > > > >>>>>>>>>>>> to speak up! :)
>> >> > > > >>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>> Cordova repositories have two main branches:
>> >> > > > >>>>>>>>>>>> 1. master
>> >> > > > >>>>>>>>>>>> 2. next
>> >> > > > >>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>> Topic branches exist for collaborating on
>>features,
>> >>or
>> >> for
>> >> > > > >>>>>>>>> code-review
>> >> > > > >>>>>>>>>>>> purposes.
>> >> > > > >>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>> Cordova uses tags to label releases.
>> >> > > > >>>>>>>>>>>> - Each release candidate has a tag. e.g.
>>"2.2.0rc1"
>> >> > > > >>>>>>>>>>>> - Each release has a tag. e.g. "2.2.0"
>> >> > > > >>>>>>>>>>>> - The "latest" tag points to the last stable
>>release
>> >> (this
>> >> > > > >>>>>>> follows
>> >> > > > >>>>>>>>> npm
>> >> > > > >>>>>>>>>>>> conventions)
>> >> > > > >>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>> 1. The "next" branch.
>> >> > > > >>>>>>>>>>>> - This branch is used only when in the process of
>> >>doing
>> >> a
>> >> > > > >>>>>>> release.
>> >> > > > >>>>>>>>>>>> - All tags are created from this branch.
>> >> > > > >>>>>>>>>>>> - All release-candidate bug-fixes are done on this
>> >> branch.
>> >> > > > >>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>> 2. The "master" branch.
>> >> > > > >>>>>>>>>>>> - When not in the release-process, all commits are
>> >>made
>> >> > here
>> >> > > > >>>>>>>>>>>> - When in the release-process, all non-bugfix
>>commits
>> >> are
>> >> > > > >>>>>> made
>> >> > > > >>>>>>>> here
>> >> > > > >>>>>>>>>>>> - This is where topic-branches are merged into.
>> >> > > > >>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>> Cutting a release:
>> >> > > > >>>>>>>>>>>> 1. git checkout next && git merge --ff-only master
>> >> > > > >>>>>>>>>>>> 2. Test test test!
>> >> > > > >>>>>>>>>>>> 3. Fix bugs by committing them directly to "next"
>>and
>> >> then
>> >> > > > >>>>>> doing
>> >> > > > >>>>>>> a
>> >> > > > >>>>>>>>>> non-ff
>> >> > > > >>>>>>>>>>>> merge of next into master
>> >> > > > >>>>>>>>>>>> 4. Tag release candidate
>> >> > > > >>>>>>>>>>>> 5. Repeat steps 2-4 as necessary
>> >> > > > >>>>>>>>>>>> 6. Tag the release (both by version and by
>>updating
>> >>the
>> >> > > > >>>>>> "latest"
>> >> > > > >>>>>>>> tag)
>> >> > > > >>>>>>>>>>>> 7. Create distribution .zip file
>> >> > > > >>>>>>>>>>>> 8. Test one last time using the dist files
>> >> > > > >>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>> Thanks,
>> >> > > > >>>>>>>>>>>>> Michael
>> >> > > > >>>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>> On Wed, Jan 23, 2013 at 11:25 AM, Brian LeRoux <
>> >> > b@brian.io
>> >> > > > >>>>>>>
>> >> > > > >>>>>>>> wrote:
>> >> > > > >>>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>>> I'm liking it. Start in 2.5?
>> >> > > > >>>>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>>> On Wed, Jan 23, 2013 at 1:19 PM, Filip Maj <
>> >> > fil@adobe.com
>> >> > > > >>>>>>>
>> >> > > > >>>>>>>> wrote:
>> >> > > > >>>>>>>>>>>>>>> Looks great Andrew!
>> >> > > > >>>>>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>>>> If everyone's on board, how are we going to
>>test
>> >>run
>> >> > > > >>>>>> this?
>> >> > > > >>>>>>>> Flip a
>> >> > > > >>>>>>>>>>>>> switch
>> >> > > > >>>>>>>>>>>>>>> at a certain point, give it a shot with one
>>repo
>> >>for
>> >> > one
>> >> > > > >>>>>> RC?
>> >> > > > >>>>>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>>>> On 1/22/13 12:29 PM, "Andrew Grieve" <
>> >> > > > >>>>>> agrieve@chromium.org>
>> >> > > > >>>>>>>>> wrote:
>> >> > > > >>>>>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>>>>> Braden, you're right. I've now done some local
>> >> playing
>> >> > > > >>>>>>> around
>> >> > > > >>>>>>>> in
>> >> > > > >>>>>>>>>>> git,
>> >> > > > >>>>>>>>>>>>> and
>> >> > > > >>>>>>>>>>>>>>>> have an updated proposal that uses merges
>> >>instead of
>> >> > > > >>>>>>> deleting
>> >> > > > >>>>>>>>>>>> branches.
>> >> > > > >>>>>>>>>>>>>>>> PTAL:
>> >> > > > >>>>>>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>>>>> Cordova repositories have three main branches:
>> >> > > > >>>>>>>>>>>>>>>> 1. stable
>> >> > > > >>>>>>>>>>>>>>>> 2. next
>> >> > > > >>>>>>>>>>>>>>>> 3. dev
>> >> > > > >>>>>>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>>>>> Topic branches also exist for collaborating on
>> >> > > > >>>>>> features, or
>> >> > > > >>>>>>>> for
>> >> > > > >>>>>>>>>>>>>>>> code-review
>> >> > > > >>>>>>>>>>>>>>>> purposes.
>> >> > > > >>>>>>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>>>>> There is *no* master branch, so that
>> >> community-driven
>> >> > > > >>>>>> pull
>> >> > > > >>>>>>>>>> requests
>> >> > > > >>>>>>>>>>>>> will
>> >> > > > >>>>>>>>>>>>>>>> be
>> >> > > > >>>>>>>>>>>>>>>> forced to think about which branch to request
>> >> against.
>> >> > > > >>>>>>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>>>>> 1. The "stable" branch.
>> >> > > > >>>>>>>>>>>>>>>> - Sits at the latest stable release of cordova
>> >> > > > >>>>>>>>>>>>>>>> - This changes only when doing fast-forward
>> >>merges
>> >> > from
>> >> > > > >>>>>>> "next"
>> >> > > > >>>>>>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>>>>> 2. The "next" branch.
>> >> > > > >>>>>>>>>>>>>>>> - This branch is used only when in the
>>process of
>> >> > doing
>> >> > > > >>>>>> a
>> >> > > > >>>>>>>>> release.
>> >> > > > >>>>>>>>>>>>>>>> - All tags (both stable and RC) are done on
>>this
>> >> > branch.
>> >> > > > >>>>>>>>>>>>>>>> - All release-candidate bug-fixes are done on
>> >>this
>> >> > > > >>>>>> branch.
>> >> > > > >>>>>>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>>>>> 3. The "dev" branch.
>> >> > > > >>>>>>>>>>>>>>>> - This is where non-release-candidate commits
>>are
>> >> done
>> >> > > > >>>>>>>>>>>>>>>> - This is where topic-branches are merged
>>into.
>> >> > > > >>>>>>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>>>>> Cutting a release:
>> >> > > > >>>>>>>>>>>>>>>> 1. git checkout next && git merge --ff-only
>>dev
>> >> > > > >>>>>>>>>>>>>>>> 2. Test test test!
>> >> > > > >>>>>>>>>>>>>>>> 3. Fix bugs by committing them directly to
>>"next"
>> >> and
>> >> > > > >>>>>> then
>> >> > > > >>>>>>>>> doing a
>> >> > > > >>>>>>>>>>>>> non-ff
>> >> > > > >>>>>>>>>>>>>>>> merge of next into dev
>> >> > > > >>>>>>>>>>>>>>>> 4. Tag release candidate
>> >> > > > >>>>>>>>>>>>>>>> 5. Repeat steps 2-4 as necessary
>> >> > > > >>>>>>>>>>>>>>>> 6. Tag the release
>> >> > > > >>>>>>>>>>>>>>>> 7. Create distribution .zip file
>> >> > > > >>>>>>>>>>>>>>>> 8. Test one last time using the dist files
>> >> > > > >>>>>>>>>>>>>>>> 9. git checkout stable && git merge --ff-only
>> >>next
>> >> > > > >>>>>>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>>>>> On Tue, Jan 22, 2013 at 1:59 PM, Braden
>> >>Shepherdson
>> >> > > > >>>>>>>>>>>>>>>> <br...@chromium.org>wrote:
>> >> > > > >>>>>>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>>>>>> I think deleting and recreating branches with
>> >>the
>> >> > same
>> >> > > > >>>>>> name
>> >> > > > >>>>>>>> can
>> >> > > > >>>>>>>>>>> cause
>> >> > > > >>>>>>>>>>>>>>>>> badness in git[1] because of remotes. It's
>>not
>> >> really
>> >> > > > >>>>>> the
>> >> > > > >>>>>>>> same
>> >> > > > >>>>>>>>>>> branch
>> >> > > > >>>>>>>>>>>>>> in
>> >> > > > >>>>>>>>>>>>>>>>> terms of commits, and git thinks that your
>>old
>> >> stable
>> >> > > > >>>>>> and
>> >> > > > >>>>>>> the
>> >> > > > >>>>>>>>> new
>> >> > > > >>>>>>>>>>>>>> stable
>> >> > > > >>>>>>>>>>>>>>>>> differ by all of each of their commits. Tags
>> >>can be
>> >> > > > >>>>>> moved
>> >> > > > >>>>>>>>>>>>> arbitrarily,
>> >> > > > >>>>>>>>>>>>>>>>> so I
>> >> > > > >>>>>>>>>>>>>>>>> think stable makes sense as a tag. I'm not
>>sure
>> >> about
>> >> > > > >>>>>> how
>> >> > > > >>>>>>>> best
>> >> > > > >>>>>>>>> to
>> >> > > > >>>>>>>>>>>>>> handle
>> >> > > > >>>>>>>>>>>>>>>>> next.
>> >> > > > >>>>>>>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>>>>>> [1]
>> >> > > > >>>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>
>> >> > > > >>>>>>>>>>
>> >> > > > >>>>>>>>>
>> >> > > > >>>>>>>>
>> >> > > > >>>>>>>
>> >> > > > >>>>>>
>> >> > > > >>
>> >> > > >
>> >> > >
>> >> >
>> >>
>> >>
>>
>>http://stackoverflow.com/questions/11844581/git-delete-and-recreate-branc
>> >> > > > >>>>>>>>>>>>>>>>> h
>> >> > > > >>>>>>>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>>>>>> On Tue, Jan 22, 2013 at 11:31 AM, Andrew
>>Grieve
>> >><
>> >> > > > >>>>>>>>>>>>> agrieve@chromium.org
>> >> > > > >>>>>>>>>>>>>>>>>> wrote:
>> >> > > > >>>>>>>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>>>>>>> Michal's attending hackathons for the week,
>>and
>> >> I'm
>> >> > > > >>>>>> not
>> >> > > > >>>>>>> sure
>> >> > > > >>>>>>>>> we
>> >> > > > >>>>>>>>>>>>> need
>> >> > > > >>>>>>>>>>>>>>>>> to
>> >> > > > >>>>>>>>>>>>>>>>> do
>> >> > > > >>>>>>>>>>>>>>>>>> a hang-out for this, as I think we really
>>are
>> >> quite
>> >> > > > >>>>>> close
>> >> > > > >>>>>>> to
>> >> > > > >>>>>>>>>>>>>> resolving
>> >> > > > >>>>>>>>>>>>>>>>>> this. I'd really like to resolve this ASAP
>>so
>> >>that
>> >> > we
>> >> > > > >>>>>>> don't
>> >> > > > >>>>>>>>> need
>> >> > > > >>>>>>>>>>> to
>> >> > > > >>>>>>>>>>>>>>>>> have
>> >> > > > >>>>>>>>>>>>>>>>> a
>> >> > > > >>>>>>>>>>>>>>>>>> code-freeze for this release.
>> >> > > > >>>>>>>>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>>>>>>> Here's a proposal:
>> >> > > > >>>>>>>>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>>>>>>> Cordova repositories have three main
>>branches:
>> >> > > > >>>>>>>>>>>>>>>>>> 1. stable
>> >> > > > >>>>>>>>>>>>>>>>>> 2. next
>> >> > > > >>>>>>>>>>>>>>>>>> 3. dev
>> >> > > > >>>>>>>>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>>>>>>> Topic branches also exist for collaborating
>>on
>> >> > > > >>>>>> features,
>> >> > > > >>>>>>> or
>> >> > > > >>>>>>>>> for
>> >> > > > >>>>>>>>>>>>>>>>> code-review
>> >> > > > >>>>>>>>>>>>>>>>>> purposes.
>> >> > > > >>>>>>>>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>>>>>>> There is *no* master branch, so that
>> >> > community-driven
>> >> > > > >>>>>> pull
>> >> > > > >>>>>>>>>>> requests
>> >> > > > >>>>>>>>>>>>>>>>> will
>> >> > > > >>>>>>>>>>>>>>>>> be
>> >> > > > >>>>>>>>>>>>>>>>>> forced to think about which branch to
>>request
>> >> > against.
>> >> > > > >>>>>>>>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>>>>>>> 1. The "stable" branch.
>> >> > > > >>>>>>>>>>>>>>>>>> - Sits at the latest stable release of
>>cordova
>> >> > > > >>>>>>>>>>>>>>>>>> - No one ever commits to the "stable"
>>branch.
>> >>It
>> >> > > > >>>>>> exists
>> >> > > > >>>>>>> only
>> >> > > > >>>>>>>>> as
>> >> > > > >>>>>>>>>> a
>> >> > > > >>>>>>>>>>>>>>>>>> short-cut for checking out the latest stable
>> >>tag.
>> >> > > > >>>>>>>>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>>>>>>> 2. The "next" branch.
>> >> > > > >>>>>>>>>>>>>>>>>> - This branch exists only when in the
>>process
>> >>of
>> >> > > > >>>>>> doing a
>> >> > > > >>>>>>>>>> release.
>> >> > > > >>>>>>>>>>>>>>>>>> - All tags (both stable and RC) are done on
>> >>this
>> >> > > > >>>>>> branch.
>> >> > > > >>>>>>>>>>>>>>>>>> - When a stable tag is done:
>> >> > > > >>>>>>>>>>>>>>>>>> - The existing "stable" branch is deleted
>> >> > > > >>>>>>>>>>>>>>>>>> - A new "stable" branch is created from
>> >>"next".
>> >> > > > >>>>>>>>>>>>>>>>>> - The "next" branch is deleted.
>> >> > > > >>>>>>>>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>>>>>>> 3. The "dev" branch.
>> >> > > > >>>>>>>>>>>>>>>>>> - This is where all commits are done
>> >> > > > >>>>>>>>>>>>>>>>>> - This is where topic-branches are merged
>>into.
>> >> > > > >>>>>>>>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>>>>>>> Cutting a release:
>> >> > > > >>>>>>>>>>>>>>>>>> 1. Create "next" from the HEAD of "dev"
>> >> > > > >>>>>>>>>>>>>>>>>> 2. Test test test!
>> >> > > > >>>>>>>>>>>>>>>>>> 3. Fix bugs by committing them to "dev" and
>> >>then
>> >> > > > >>>>>>>>> cherry-picking
>> >> > > > >>>>>>>>>>>>> them
>> >> > > > >>>>>>>>>>>>>>>>> into
>> >> > > > >>>>>>>>>>>>>>>>>> "next"
>> >> > > > >>>>>>>>>>>>>>>>>> 4. Tag release candidate
>> >> > > > >>>>>>>>>>>>>>>>>> 5. Repeat steps 2-4 as necessary
>> >> > > > >>>>>>>>>>>>>>>>>> 6. Tag the release
>> >> > > > >>>>>>>>>>>>>>>>>> 7. Create distribution .zip file
>> >> > > > >>>>>>>>>>>>>>>>>> 8. Test one last time using the dist files
>> >> > > > >>>>>>>>>>>>>>>>>> 9. Delete "stable"
>> >> > > > >>>>>>>>>>>>>>>>>> 10. Create a new "stable" by branching from
>>the
>> >> HEAD
>> >> > > > >>>>>> of
>> >> > > > >>>>>>>> "next"
>> >> > > > >>>>>>>>>>>>>>>>>> 11. Delete the "next" branch
>> >> > > > >>>>>>>>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>>>>>>> On Wed, Jan 16, 2013 at 10:34 AM, Michal
>>Mocny
>> >><
>> >> > > > >>>>>>>>>>>>> mmocny@chromium.org>
>> >> > > > >>>>>>>>>>>>>>>>>> wrote:
>> >> > > > >>>>>>>>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>>>>>>>> Just going to throw out one of my personal
>> >> > > > >>>>>> requirements
>> >> > > > >>>>>>> for
>> >> > > > >>>>>>>>>>>>>> whatever
>> >> > > > >>>>>>>>>>>>>>>>>>> proposal we come up with, so it doesn't get
>> >>lost:
>> >> > > > >>>>>>>>>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>>>>>>>> * Feature branches are great for feature
>>work
>> >> > and/or
>> >> > > > >>>>>>> large
>> >> > > > >>>>>>>>>>>>> sweeping
>> >> > > > >>>>>>>>>>>>>>>>>>> changes, as are JIRA bugs for tracking
>>them,
>> >>but
>> >> > > > >>>>>> cordova
>> >> > > > >>>>>>>> has
>> >> > > > >>>>>>>>>> many
>> >> > > > >>>>>>>>>>>>>>>>> many
>> >> > > > >>>>>>>>>>>>>>>>>>> trivial issues that could be fixed with
>> >> "drive-by"
>> >> > > > >>>>>>> patches
>> >> > > > >>>>>>>>> that
>> >> > > > >>>>>>>>>>>>>>>>> require
>> >> > > > >>>>>>>>>>>>>>>>>> as
>> >> > > > >>>>>>>>>>>>>>>>>>> little friction to commit as possible.
>> >> > > > >>>>>>>>>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>>>>>>>> On Tue, Jan 15, 2013 at 3:05 PM, Marcel
>> >>Kinard <
>> >> > > > >>>>>>>>>>>>> cmarcelk@gmail.com
>> >> > > > >>>>>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>>>>>>> wrote:
>> >> > > > >>>>>>>>>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>>>>>>>>> How about if there is a specific straw man
>> >> > proposal
>> >> > > > >>>>>> at
>> >> > > > >>>>>>> the
>> >> > > > >>>>>>>>>>>>>>>>> beginning
>> >> > > > >>>>>>>>>>>>>>>>> of
>> >> > > > >>>>>>>>>>>>>>>>>>>> the face-time? Then the folks that are in
>> >> > agreement
>> >> > > > >>>>>>> won't
>> >> > > > >>>>>>>>> need
>> >> > > > >>>>>>>>>>>>> to
>> >> > > > >>>>>>>>>>>>>>>>> say
>> >> > > > >>>>>>>>>>>>>>>>>>>> anything ;-)
>> >> > > > >>>>>>>>>>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>>>>>>>>> Seriously, making adjustments to something
>> >> > tangible
>> >> > > > >>>>>> is
>> >> > > > >>>>>>>>> easier
>> >> > > > >>>>>>>>>>>>>> than
>> >> > > > >>>>>>>>>>>>>>>>>>>> instantiating it from scratch. A volunteer
>> >>for a
>> >> > > > >>>>>> very
>> >> > > > >>>>>>>> simple
>> >> > > > >>>>>>>>>>>>>>>>> writeup
>> >> > > > >>>>>>>>>>>>>>>>> on
>> >> > > > >>>>>>>>>>>>>>>>>>> the
>> >> > > > >>>>>>>>>>>>>>>>>>>> wiki?
>> >> > > > >>>>>>>>>>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>>>>>>>>> -- Marcel Kinard
>> >> > > > >>>>>>>>>>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>>>>>>>>> On 1/14/2013 10:06 PM, Michal Mocny wrote:
>> >> > > > >>>>>>>>>>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>>>>>>>>>> Okay gentlemen, I think there have been
>> >> countless
>> >> > > > >>>>>> good
>> >> > > > >>>>>>>>> points
>> >> > > > >>>>>>>>>>>>>>>>> made
>> >> > > > >>>>>>>>>>>>>>>>>> from
>> >> > > > >>>>>>>>>>>>>>>>>>>>> all
>> >> > > > >>>>>>>>>>>>>>>>>>>>> parties, but also some bike-shedding.
>> >> > > > >>>>>>>>>>>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>>>>>>>>>> Perhaps it is time to schedule some
>> >>face-time
>> >> to
>> >> > > > >>>>>> better
>> >> > > > >>>>>>>>>>>>>>>>> articulate
>> >> > > > >>>>>>>>>>>>>>>>>> some
>> >> > > > >>>>>>>>>>>>>>>>>>> of
>> >> > > > >>>>>>>>>>>>>>>>>>>>> the finer points, and to help come to
>>some
>> >> > > > >>>>>> consensus?
>> >> > > > >>>>>>>>>>>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>>>>>>>>>> -Michal
>> >> > > > >>>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>>
>> >> > > > >>>>>>>>>>>
>> >> > > > >>>>>>>>>>
>> >> > > > >>>>>>>>>>
>> >> > > > >>>>>>>>>>
>> >> > > > >>>>>>>>>> --
>> >> > > > >>>>>>>>>> @purplecabbage
>> >> > > > >>>>>>>>>> risingj.com
>> >> > > > >>>>>>>>>>
>> >> > > > >>>>>>>>>
>> >> > > > >>>>>>>>
>> >> > > > >>>>>>>
>> >> > > > >>>>>>>
>> >> > > > >>>>>>>
>> >> > > > >>>>>>> --
>> >> > > > >>>>>>> @purplecabbage
>> >> > > > >>>>>>> risingj.com
>> >> > > > >>>>>>>
>> >> > > > >>>>>>
>> >> > > > >>>>>
>> >> > > > >>>>>
>> >> > > > >>>>
>> >> > > > >>>
>> >> > > > >>>
>> >> > > > >>> --
>> >> > > > >>> @purplecabbage
>> >> > > > >>> risingj.com
>> >> > > > >>
>> >> > > > >>
>> >> > > >
>> >> > > >
>> >> > >
>> >> >
>> >>
>>
>>
Re: too long to package a release?
Posted by Andrew Grieve <ag...@chromium.org>.
Step 5 here: http://wiki.apache.org/cordova/CommitterWorkflow
Probably it should be "isFixingRegression" instead of "isBugFix". I'll
update it now.
On Wed, Feb 20, 2013 at 1:59 PM, Filip Maj <fi...@adobe.com> wrote:
> I noticed on iOS the commits going into next are mirrored on master.
>
> For Android that was not done.
>
> What is the correct process?
>
> On 2/20/13 10:12 AM, "Michal Mocny" <mm...@chromium.org> wrote:
>
> >oooo I didn't know that. Thanks!
> >
> >
> >On Wed, Feb 20, 2013 at 1:10 PM, Becky Gibson
> ><gi...@gmail.com>wrote:
> >
> >> Thank you, Michael! I do usually go a git push --dry-run to check that
> >>I
> >> am pushing what I expect but I'll try the diff as well.
> >>
> >>
> >> On Wed, Feb 20, 2013 at 1:07 PM, Michal Mocny <mm...@chromium.org>
> >>wrote:
> >>
> >> > So there is also http://wiki.apache.org/cordova/CuttingReleases which
> >> may
> >> > be useful (esp Taggin section).
> >> >
> >> > As far as the confusion with the two branch names: "topic_branch" is
> >>your
> >> > local working branch for a bugfix/feature, and "to_be_merged" is
> >>really
> >> > "temporary_new_name_for_a_branch_to_do_rebase_in". I usually skip
> >>that
> >> > step and take the risk or rebasing in topic_branch (aside: this may
> >> > negatively affect diffs if you push updates for a
> >>review-edit-re-review
> >> > cycle -- but this isn't an issue for cordova).
> >> >
> >> > Do not checkout 'next' into your master branch. Update your local
> >> branches
> >> > to include the remote next branch (with 'git pull apache' with no
> >>branch)
> >> > then you can switch to the next branch locally, apply your patch
> >>there,
> >> and
> >> > push to that remote branch directly. Later, merge that commit into
> >> master
> >> > locally, and push that.
> >> >
> >> > Do not push to apache next from your local master, or else you will
> >>push
> >> > all the changes.
> >> >
> >> > I agree, this is a little confusing, but after a few practice runs it
> >> > should be easy to figure out. You should probably also check what
> >>would
> >> be
> >> > pushed with 'git diff apache/[target-branch]' or tag on --stat to
> >>that to
> >> > just see that files that would signal a quick "uh-oh".
> >> >
> >> > I'll work to update the wiki later today, and likely others will have
> >> more
> >> > tips on how to make sure we don't make mistakes.
> >> >
> >> > -Michal
> >> >
> >> >
> >> >
> >> > On Wed, Feb 20, 2013 at 12:42 PM, Becky Gibson <
> gibson.becky@gmail.com
> >> > >wrote:
> >> >
> >> > > Can someone please provide a "git cordova release process for
> >>dummies"
> >> > > example to make sure I do the release commits and merges properly
> >>(the
> >> > > committerWorkflow example didn't help me as I didn't understand the
> >> > > topic_branch and to_be_merged distinction)
> >> > >
> >> > > At any rate, can I do a git checkout apache next into my "master"
> >> branch?
> >> > > Then I can checkout my working_branch, rebase master (which
> >>contains
> >> > the
> >> > > next code) checkout master, merge my fix and push apache next.
> >> > > git checkout apache next
> >> > > git checkout working_branch_with_fix
> >> > > git rebase master
> >> > > git checkout master
> >> > > git merge working_branch_with_fix
> >> > > git push apache next
> >> > >
> >> > > and then repeat this for apache master with the possibility of
> >>needing
> >> to
> >> > > use -ff when I merge. Am I on the right track?
> >> > >
> >> > > humbled by git,
> >> > > -becky
> >> > >
> >> > > On Fri, Feb 8, 2013 at 5:22 PM, Marcel Kinard <cm...@gmail.com>
> >> > wrote:
> >> > >
> >> > > > Nice! Thanks, Andrew!
> >> > > >
> >> > > > -- Marcel Kinard
> >> > > >
> >> > > > On Feb 7, 2013, at 2:59 PM, Andrew Grieve <ag...@chromium.org>
> >> > wrote:
> >> > > >
> >> > > > > The doc's not up-to-date, but I think we ended on consensus for
> >>the
> >> > > code
> >> > > > > version. I've taken a stab at updating the wiki pages:
> >> > > > >
> >> > > > > http://wiki.apache.org/cordova/CordovaAndGit -- Added the idea
> >>of
> >> > > > having
> >> > > > > both a master and a next branch
> >> > > > > http://wiki.apache.org/cordova/CommitterWorkflow -- Added
> >>Jesse's
> >> > > > version
> >> > > > > of the "which branch - in code"
> >> > > > > http://wiki.apache.org/cordova/CuttingReleases -- Changed
> >>tagging
> >> > > > > instructions to refer to the "next" branch
> >> > > > >
> >> > > > >
> >> > > > > On Thu, Feb 7, 2013 at 1:26 PM, Marcel Kinard
> >><cm...@gmail.com>
> >> > > > wrote:
> >> > > > >
> >> > > > >> With 2.5 starting, it appears time to poke this thread.
> >> > > > >>
> >> > > > >> - Is the Google doc refreshed with the latest consensus?
> >> > > > >> - If so, should the Google doc be transferred to a wiki page?
> >> > > > >> - Have the necessary branches been created?
> >> > > > >> - Are we all in the boat, and understand how to row this beast?
> >> > > > >>
> >> > > > >> -- Marcel Kinard
> >> > > > >>
> >> > > > >> On Jan 24, 2013, at 5:14 PM, Jesse <pu...@gmail.com>
> >> wrote:
> >> > > > >>
> >> > > > >>> Nice Shaz, but I was hoping it was a github style network
> >> > > visualization
> >> > > > >>> that included a few versions worth of merges.
> >> > > > >>> Who wants to draw that?
> >> > > > >>>
> >> > > > >>> On Thu, Jan 24, 2013 at 2:05 PM, Shazron <sh...@gmail.com>
> >> > wrote:
> >> > > > >>>
> >> > > > >>>> Inline image got mangled, here it is linked:
> >>http://cl.ly/MOrD
> >> > > > >>>>
> >> > > > >>>>
> >> > > > >>>> On Thu, Jan 24, 2013 at 1:39 PM, Shazron <sh...@gmail.com>
> >> > wrote:
> >> > > > >>>>
> >> > > > >>>>> Thanks for the pseudocode Andrew, seems simpler to
> >>understand
> >> ;)
> >> > > > >> Jesse's
> >> > > > >>>>> re-factor makes it even easier. Here's my contrib for those
> >> more
> >> > > > >> visually
> >> > > > >>>>> inclined:
> >> > > > >>>>>
> >> > > > >>>>>
> >> > > > >>>>> [image: Inline image 2]
> >> > > > >>>>>
> >> > > > >>>>>
> >> > > > >>>>> On Thu, Jan 24, 2013 at 1:29 PM, Andrew Grieve <
> >> > > agrieve@chromium.org
> >> > > > >>> wrote:
> >> > > > >>>>>
> >> > > > >>>>>> Nice! even simpler. :)
> >> > > > >>>>>>
> >> > > > >>>>>>
> >> > > > >>>>>> On Thu, Jan 24, 2013 at 3:44 PM, Jesse <
> >> purplecabbage@gmail.com
> >> > >
> >> > > > >> wrote:
> >> > > > >>>>>>
> >> > > > >>>>>>> Thanks for clarifying Andrew. et al, I guess I was
> >> > > > mis-understanding
> >> > > > >>>>>> some
> >> > > > >>>>>>> of the earlier discussion around naming stuff.
> >> > > > >>>>>>>
> >> > > > >>>>>>> So everything is going to master all the time, and we only
> >> care
> >> > > > about
> >> > > > >>>>>>> 'next' if we are inReleaseMode and it is a bug fix?
> >> > > > >>>>>>>
> >> > > > >>>>>>> if(inReleaseMode && isBugFix) {
> >> > > > >>>>>>> commitToBranch('next');
> >> > > > >>>>>>> mergeBranch('next').into('master');
> >> > > > >>>>>>> }
> >> > > > >>>>>>> else {
> >> > > > >>>>>>> commitToBranch('master');
> >> > > > >>>>>>> }
> >> > > > >>>>>>>
> >> > > > >>>>>>>
> >> > > > >>>>>>>
> >> > > > >>>>>>>
> >> > > > >>>>>>>
> >> > > > >>>>>>> On Thu, Jan 24, 2013 at 12:29 PM, Andrew Grieve <
> >> > > > >> agrieve@chromium.org
> >> > > > >>>>>>>> wrote:
> >> > > > >>>>>>>
> >> > > > >>>>>>>> Just to clarify - there should be *no* using of the git
> >> > > > >>>>>> cherry-picking
> >> > > > >>>>>>>> command, only git merge.
> >> > > > >>>>>>>>
> >> > > > >>>>>>>> Jesse - not sure what you're referring to with "branch
> >>must
> >> be
> >> > > > named
> >> > > > >>>>>> x".
> >> > > > >>>>>>>> The latest revision of the proposal has only two
> >>branches:
> >> > > master
> >> > > > >> and
> >> > > > >>>>>>> next.
> >> > > > >>>>>>>> Do you mean you don't like the name "next"?
> >> > > > >>>>>>>>
> >> > > > >>>>>>>> Maybe the proposal will seem simpler if put in the form
> >>of
> >> > code
> >> > > :)
> >> > > > >>>>>>>>
> >> > > > >>>>>>>> if (!inReleaseMode) {
> >> > > > >>>>>>>> commitToBranch('master');
> >> > > > >>>>>>>> } else {
> >> > > > >>>>>>>> if (isBugFix) {
> >> > > > >>>>>>>> commitToBranch('next');
> >> > > > >>>>>>>> mergeBranch('next').into('master');
> >> > > > >>>>>>>> } else {
> >> > > > >>>>>>>> commitToBranch('master');
> >> > > > >>>>>>>> }
> >> > > > >>>>>>>> }
> >> > > > >>>>>>>>
> >> > > > >>>>>>>>
> >> > > > >>>>>>>> On Thu, Jan 24, 2013 at 3:06 PM, Braden Shepherdson <
> >> > > > >>>>>> braden@chromium.org
> >> > > > >>>>>>>>> wrote:
> >> > > > >>>>>>>>
> >> > > > >>>>>>>>> Most of the time the flow will be unchanged: push to
> >> master.
> >> > > > >>>>>> Tagging
> >> > > > >>>>>>>> things
> >> > > > >>>>>>>>> we already know how to do; that doesn't change.
> >> > > > >>>>>>>>>
> >> > > > >>>>>>>>> The only new flow for most people is cherrypicking bug
> >> fixes
> >> > > from
> >> > > > >>>>>>> master
> >> > > > >>>>>>>> to
> >> > > > >>>>>>>>> next, which we can give examples of. Plus that could
> >>remain
> >> > the
> >> > > > >>>>>>>>> responsibility of the main platform maintainers, who are
> >> > doing
> >> > > > the
> >> > > > >>>>>>>> tagging.
> >> > > > >>>>>>>>>
> >> > > > >>>>>>>>> Braden
> >> > > > >>>>>>>>>
> >> > > > >>>>>>>>>
> >> > > > >>>>>>>>> On Thu, Jan 24, 2013 at 2:56 PM, Jesse <
> >> > > purplecabbage@gmail.com>
> >> > > > >>>>>>> wrote:
> >> > > > >>>>>>>>>
> >> > > > >>>>>>>>>> On Thu, Jan 24, 2013 at 11:09 AM, Braden Shepherdson <
> >> > > > >>>>>>>>> braden@chromium.org
> >> > > > >>>>>>>>>>> wrote:
> >> > > > >>>>>>>>>>
> >> > > > >>>>>>>>>>> The founding goal we're trying to accomplish here is
> >>that
> >> > we
> >> > > > >>>>>> don't
> >> > > > >>>>>>>> want
> >> > > > >>>>>>>>>>> everyone sitting on changes to be in the next version
> >> while
> >> > > we
> >> > > > >>>>>> use
> >> > > > >>>>>>>>> master
> >> > > > >>>>>>>>>>> to prep a release.
> >> > > > >>>>>>>>>>>
> >> > > > >>>>>>>>>>> I don't think having one branch for prepping the
> >>release
> >> > and
> >> > > > >>>>>>> another
> >> > > > >>>>>>>>> for
> >> > > > >>>>>>>>>>> main development is a lot of bureaucracy.
> >> > > > >>>>>>>>>>>
> >> > > > >>>>>>>>>>
> >> > > > >>>>>>>>>> It is not, the 'branch must be named x' is mainly
> >>where I
> >> > have
> >> > > > >>>>>>>> concerns.
> >> > > > >>>>>>>>>> Really I just want things simple.
> >> > > > >>>>>>>>>>
> >> > > > >>>>>>>>>>
> >> > > > >>>>>>>>>>>
> >> > > > >>>>>>>>>>>
> >> > > > >>>>>>>>>>> On Thu, Jan 24, 2013 at 1:57 PM, Jesse MacFadyen <
> >> > > > >>>>>>>>>> purplecabbage@gmail.com
> >> > > > >>>>>>>>>>>> wrote:
> >> > > > >>>>>>>>>>>
> >> > > > >>>>>>>>>>>> I have been quietly listening on this thread, but
> >> thought
> >> > I
> >> > > > >>>>>>> should
> >> > > > >>>>>>>> at
> >> > > > >>>>>>>>>>>> least share my opinion.
> >> > > > >>>>>>>>>>>>
> >> > > > >>>>>>>>>>>> I don't think adding contribution rules helps anyone.
> >> Git
> >> > is
> >> > > > >>>>>>>>>>>> complicated enough as it is, and this just all seems
> >> like
> >> > > > >>>>>>>>> bureaucracy.
> >> > > > >>>>>>>>>>>>
> >> > > > >>>>>>>>>>>> I think master should always contain the latest
> >>stable
> >> > code,
> >> > > > >>>>>> and
> >> > > > >>>>>>> be
> >> > > > >>>>>>>>>>>> periodically tagged with rc's and versions.
> >> > > > >>>>>>>>>>>> All work should be done in personal forks and feature
> >> > > > >>>>>> branches.
> >> > > > >>>>>>>>>>>> If the latest tag of master is an rc, then we should
> >> only
> >> > be
> >> > > > >>>>>>>> merging
> >> > > > >>>>>>>>>>>> bugfixes, until the release.
> >> > > > >>>>>>>>>>>> Immediately after tagging a version we decide which
> >> > feature
> >> > > > >>>>>>>> branches
> >> > > > >>>>>>>>>>>> and pull requests to pull in, and go for it.
> >> > > > >>>>>>>>>>>>
> >> > > > >>>>>>>>>>>> I don't think this is much different from what we
> >>have,
> >> > but
> >> > > I
> >> > > > >>>>>>> think
> >> > > > >>>>>>>>>>>> that is good.
> >> > > > >>>>>>>>>>>> The suggestions thus far, while interesting, don't
> >> > increase
> >> > > > >>>>>> our
> >> > > > >>>>>>>>>>>> velocity in my opinion. Also, I can also pretty much
> >> > > guaranty
> >> > > > >>>>>>> I'll
> >> > > > >>>>>>>>>>>> screw it up for the next 3-4 versions. ( because I'm
> >> dumb
> >> > )
> >> > > > >>>>>>>>>>>>
> >> > > > >>>>>>>>>>>> Cheers,
> >> > > > >>>>>>>>>>>> Jesse
> >> > > > >>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>
> >> > > > >>>>>>>>>>>> On 2013-01-24, at 5:53 AM, Andrew Grieve <
> >> > > > >>>>>> agrieve@chromium.org>
> >> > > > >>>>>>>>> wrote:
> >> > > > >>>>>>>>>>>>
> >> > > > >>>>>>>>>>>> On Wed, Jan 23, 2013 at 4:58 PM, Michael Brooks <
> >> > > > >>>>>>>>>>> michael@michaelbrooks.ca
> >> > > > >>>>>>>>>>>>> wrote:
> >> > > > >>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>> Before we move forward, I have a few questions about
> >> the
> >> > > > >>>>>> "no
> >> > > > >>>>>>>>> master"
> >> > > > >>>>>>>>>>>>> approach.
> >> > > > >>>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>> There is *no* master branch, so that
> >>community-driven
> >> > pull
> >> > > > >>>>>>>> requests
> >> > > > >>>>>>>>>>> will
> >> > > > >>>>>>>>>>>> be
> >> > > > >>>>>>>>>>>>>> forced to think about which branch to request
> >>against.
> >> > > > >>>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>> - Andrew, can you cite other projects that do not
> >>use a
> >> > > > >>>>>> master
> >> > > > >>>>>>>>>> branch?
> >> > > > >>>>>>>>>>>> This project is my first time using git / github, so
> >>I
> >> > don't
> >> > > > >>>>>> have
> >> > > > >>>>>>>>> much
> >> > > > >>>>>>>>>> to
> >> > > > >>>>>>>>>>>> draw from. I was going off of others' suggestions on
> >> this
> >> > > > >>>>>> thread
> >> > > > >>>>>>>>> when I
> >> > > > >>>>>>>>>>>> proposed the names.
> >> > > > >>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>> - On Github, you must have a default branch. If not
> >> > > > >>>>>> master, it
> >> > > > >>>>>>>> must
> >> > > > >>>>>>>>>> be
> >> > > > >>>>>>>>>>>>> something else. So, users are not forced to think
> >>about
> >> > the
> >> > > > >>>>>>>> branch
> >> > > > >>>>>>>>> to
> >> > > > >>>>>>>>>>>> send
> >> > > > >>>>>>>>>>>>> a pull request again... they will likely just use
> >>the
> >> > > > >>>>>> default.
> >> > > > >>>>>>>>>>>>
> >> > > > >>>>>>>>>>>> Hmm, good point. The goal is to get people
> >>downloading
> >> > > > >>>>>> Cordova
> >> > > > >>>>>>> for
> >> > > > >>>>>>>>> use
> >> > > > >>>>>>>>>> to
> >> > > > >>>>>>>>>>>> end up with Stable, and for developers to send pull
> >> > requests
> >> > > > >>>>>>>> against
> >> > > > >>>>>>>>>> dev.
> >> > > > >>>>>>>>>>>> With a forced default branch, I don't think we can
> >> > > accomplish
> >> > > > >>>>>>> this.
> >> > > > >>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>> - Why is the "stable" branch not just "master"?
> >> > > > >>>>>>>>>>>>
> >> > > > >>>>>>>>>>>> My thinking was that it's not obvious whether Master
> >>==
> >> > > > >>>>>> bleeding
> >> > > > >>>>>>>>> edge,
> >> > > > >>>>>>>>>> or
> >> > > > >>>>>>>>>>>> Master == Stable version. Using the names "dev" and
> >> > "stable"
> >> > > > >>>>>>> makes
> >> > > > >>>>>>>>> it a
> >> > > > >>>>>>>>>>> bit
> >> > > > >>>>>>>>>>>> clear.
> >> > > > >>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>
> >> > > > >>>>>>>>>>>> So... If github forces us to have a default branch,
> >>I'm
> >> > > > >>>>>> thinking
> >> > > > >>>>>>>> that
> >> > > > >>>>>>>>>>>> having users send pull requests against "dev" is more
> >> > > > >>>>>> valuable
> >> > > > >>>>>>> than
> >> > > > >>>>>>>>>>> having
> >> > > > >>>>>>>>>>>> people download the latest "stable" by default. If
> >> people
> >> > > are
> >> > > > >>>>>>>> pulling
> >> > > > >>>>>>>>>>> code
> >> > > > >>>>>>>>>>>> from github rather than from our release .zip files,
> >> then
> >> > > > >>>>>> it's
> >> > > > >>>>>>>> likely
> >> > > > >>>>>>>>>>> they
> >> > > > >>>>>>>>>>>> want to hack on it anyways, or that they want the dev
> >> > > > >>>>>> version to
> >> > > > >>>>>>>> see
> >> > > > >>>>>>>>> if
> >> > > > >>>>>>>>>>>> bugs are fixed.
> >> > > > >>>>>>>>>>>>
> >> > > > >>>>>>>>>>>> Soo.... Here's version #3! If anyone can think of
> >>how to
> >> > > > >>>>>> keep the
> >> > > > >>>>>>>>> three
> >> > > > >>>>>>>>>>>> branches while addressing being forced to have a
> >>default
> >> > > > >>>>>> branch,
> >> > > > >>>>>>>> feel
> >> > > > >>>>>>>>>>> free
> >> > > > >>>>>>>>>>>> to speak up! :)
> >> > > > >>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>
> >> > > > >>>>>>>>>>>> Cordova repositories have two main branches:
> >> > > > >>>>>>>>>>>> 1. master
> >> > > > >>>>>>>>>>>> 2. next
> >> > > > >>>>>>>>>>>>
> >> > > > >>>>>>>>>>>> Topic branches exist for collaborating on features,
> >>or
> >> for
> >> > > > >>>>>>>>> code-review
> >> > > > >>>>>>>>>>>> purposes.
> >> > > > >>>>>>>>>>>>
> >> > > > >>>>>>>>>>>> Cordova uses tags to label releases.
> >> > > > >>>>>>>>>>>> - Each release candidate has a tag. e.g. "2.2.0rc1"
> >> > > > >>>>>>>>>>>> - Each release has a tag. e.g. "2.2.0"
> >> > > > >>>>>>>>>>>> - The "latest" tag points to the last stable release
> >> (this
> >> > > > >>>>>>> follows
> >> > > > >>>>>>>>> npm
> >> > > > >>>>>>>>>>>> conventions)
> >> > > > >>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>
> >> > > > >>>>>>>>>>>> 1. The "next" branch.
> >> > > > >>>>>>>>>>>> - This branch is used only when in the process of
> >>doing
> >> a
> >> > > > >>>>>>> release.
> >> > > > >>>>>>>>>>>> - All tags are created from this branch.
> >> > > > >>>>>>>>>>>> - All release-candidate bug-fixes are done on this
> >> branch.
> >> > > > >>>>>>>>>>>>
> >> > > > >>>>>>>>>>>> 2. The "master" branch.
> >> > > > >>>>>>>>>>>> - When not in the release-process, all commits are
> >>made
> >> > here
> >> > > > >>>>>>>>>>>> - When in the release-process, all non-bugfix commits
> >> are
> >> > > > >>>>>> made
> >> > > > >>>>>>>> here
> >> > > > >>>>>>>>>>>> - This is where topic-branches are merged into.
> >> > > > >>>>>>>>>>>>
> >> > > > >>>>>>>>>>>> Cutting a release:
> >> > > > >>>>>>>>>>>> 1. git checkout next && git merge --ff-only master
> >> > > > >>>>>>>>>>>> 2. Test test test!
> >> > > > >>>>>>>>>>>> 3. Fix bugs by committing them directly to "next" and
> >> then
> >> > > > >>>>>> doing
> >> > > > >>>>>>> a
> >> > > > >>>>>>>>>> non-ff
> >> > > > >>>>>>>>>>>> merge of next into master
> >> > > > >>>>>>>>>>>> 4. Tag release candidate
> >> > > > >>>>>>>>>>>> 5. Repeat steps 2-4 as necessary
> >> > > > >>>>>>>>>>>> 6. Tag the release (both by version and by updating
> >>the
> >> > > > >>>>>> "latest"
> >> > > > >>>>>>>> tag)
> >> > > > >>>>>>>>>>>> 7. Create distribution .zip file
> >> > > > >>>>>>>>>>>> 8. Test one last time using the dist files
> >> > > > >>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>> Thanks,
> >> > > > >>>>>>>>>>>>> Michael
> >> > > > >>>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>> On Wed, Jan 23, 2013 at 11:25 AM, Brian LeRoux <
> >> > b@brian.io
> >> > > > >>>>>>>
> >> > > > >>>>>>>> wrote:
> >> > > > >>>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>>> I'm liking it. Start in 2.5?
> >> > > > >>>>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>>> On Wed, Jan 23, 2013 at 1:19 PM, Filip Maj <
> >> > fil@adobe.com
> >> > > > >>>>>>>
> >> > > > >>>>>>>> wrote:
> >> > > > >>>>>>>>>>>>>>> Looks great Andrew!
> >> > > > >>>>>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>>>> If everyone's on board, how are we going to test
> >>run
> >> > > > >>>>>> this?
> >> > > > >>>>>>>> Flip a
> >> > > > >>>>>>>>>>>>> switch
> >> > > > >>>>>>>>>>>>>>> at a certain point, give it a shot with one repo
> >>for
> >> > one
> >> > > > >>>>>> RC?
> >> > > > >>>>>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>>>> On 1/22/13 12:29 PM, "Andrew Grieve" <
> >> > > > >>>>>> agrieve@chromium.org>
> >> > > > >>>>>>>>> wrote:
> >> > > > >>>>>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>>>>> Braden, you're right. I've now done some local
> >> playing
> >> > > > >>>>>>> around
> >> > > > >>>>>>>> in
> >> > > > >>>>>>>>>>> git,
> >> > > > >>>>>>>>>>>>> and
> >> > > > >>>>>>>>>>>>>>>> have an updated proposal that uses merges
> >>instead of
> >> > > > >>>>>>> deleting
> >> > > > >>>>>>>>>>>> branches.
> >> > > > >>>>>>>>>>>>>>>> PTAL:
> >> > > > >>>>>>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>>>>> Cordova repositories have three main branches:
> >> > > > >>>>>>>>>>>>>>>> 1. stable
> >> > > > >>>>>>>>>>>>>>>> 2. next
> >> > > > >>>>>>>>>>>>>>>> 3. dev
> >> > > > >>>>>>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>>>>> Topic branches also exist for collaborating on
> >> > > > >>>>>> features, or
> >> > > > >>>>>>>> for
> >> > > > >>>>>>>>>>>>>>>> code-review
> >> > > > >>>>>>>>>>>>>>>> purposes.
> >> > > > >>>>>>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>>>>> There is *no* master branch, so that
> >> community-driven
> >> > > > >>>>>> pull
> >> > > > >>>>>>>>>> requests
> >> > > > >>>>>>>>>>>>> will
> >> > > > >>>>>>>>>>>>>>>> be
> >> > > > >>>>>>>>>>>>>>>> forced to think about which branch to request
> >> against.
> >> > > > >>>>>>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>>>>> 1. The "stable" branch.
> >> > > > >>>>>>>>>>>>>>>> - Sits at the latest stable release of cordova
> >> > > > >>>>>>>>>>>>>>>> - This changes only when doing fast-forward
> >>merges
> >> > from
> >> > > > >>>>>>> "next"
> >> > > > >>>>>>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>>>>> 2. The "next" branch.
> >> > > > >>>>>>>>>>>>>>>> - This branch is used only when in the process of
> >> > doing
> >> > > > >>>>>> a
> >> > > > >>>>>>>>> release.
> >> > > > >>>>>>>>>>>>>>>> - All tags (both stable and RC) are done on this
> >> > branch.
> >> > > > >>>>>>>>>>>>>>>> - All release-candidate bug-fixes are done on
> >>this
> >> > > > >>>>>> branch.
> >> > > > >>>>>>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>>>>> 3. The "dev" branch.
> >> > > > >>>>>>>>>>>>>>>> - This is where non-release-candidate commits are
> >> done
> >> > > > >>>>>>>>>>>>>>>> - This is where topic-branches are merged into.
> >> > > > >>>>>>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>>>>> Cutting a release:
> >> > > > >>>>>>>>>>>>>>>> 1. git checkout next && git merge --ff-only dev
> >> > > > >>>>>>>>>>>>>>>> 2. Test test test!
> >> > > > >>>>>>>>>>>>>>>> 3. Fix bugs by committing them directly to "next"
> >> and
> >> > > > >>>>>> then
> >> > > > >>>>>>>>> doing a
> >> > > > >>>>>>>>>>>>> non-ff
> >> > > > >>>>>>>>>>>>>>>> merge of next into dev
> >> > > > >>>>>>>>>>>>>>>> 4. Tag release candidate
> >> > > > >>>>>>>>>>>>>>>> 5. Repeat steps 2-4 as necessary
> >> > > > >>>>>>>>>>>>>>>> 6. Tag the release
> >> > > > >>>>>>>>>>>>>>>> 7. Create distribution .zip file
> >> > > > >>>>>>>>>>>>>>>> 8. Test one last time using the dist files
> >> > > > >>>>>>>>>>>>>>>> 9. git checkout stable && git merge --ff-only
> >>next
> >> > > > >>>>>>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>>>>> On Tue, Jan 22, 2013 at 1:59 PM, Braden
> >>Shepherdson
> >> > > > >>>>>>>>>>>>>>>> <br...@chromium.org>wrote:
> >> > > > >>>>>>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>>>>>> I think deleting and recreating branches with
> >>the
> >> > same
> >> > > > >>>>>> name
> >> > > > >>>>>>>> can
> >> > > > >>>>>>>>>>> cause
> >> > > > >>>>>>>>>>>>>>>>> badness in git[1] because of remotes. It's not
> >> really
> >> > > > >>>>>> the
> >> > > > >>>>>>>> same
> >> > > > >>>>>>>>>>> branch
> >> > > > >>>>>>>>>>>>>> in
> >> > > > >>>>>>>>>>>>>>>>> terms of commits, and git thinks that your old
> >> stable
> >> > > > >>>>>> and
> >> > > > >>>>>>> the
> >> > > > >>>>>>>>> new
> >> > > > >>>>>>>>>>>>>> stable
> >> > > > >>>>>>>>>>>>>>>>> differ by all of each of their commits. Tags
> >>can be
> >> > > > >>>>>> moved
> >> > > > >>>>>>>>>>>>> arbitrarily,
> >> > > > >>>>>>>>>>>>>>>>> so I
> >> > > > >>>>>>>>>>>>>>>>> think stable makes sense as a tag. I'm not sure
> >> about
> >> > > > >>>>>> how
> >> > > > >>>>>>>> best
> >> > > > >>>>>>>>> to
> >> > > > >>>>>>>>>>>>>> handle
> >> > > > >>>>>>>>>>>>>>>>> next.
> >> > > > >>>>>>>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>>>>>> [1]
> >> > > > >>>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>
> >> > > > >>>>>>>>>>>
> >> > > > >>>>>>>>>>
> >> > > > >>>>>>>>>
> >> > > > >>>>>>>>
> >> > > > >>>>>>>
> >> > > > >>>>>>
> >> > > > >>
> >> > > >
> >> > >
> >> >
> >>
> >>
> http://stackoverflow.com/questions/11844581/git-delete-and-recreate-branc
> >> > > > >>>>>>>>>>>>>>>>> h
> >> > > > >>>>>>>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>>>>>> On Tue, Jan 22, 2013 at 11:31 AM, Andrew Grieve
> >><
> >> > > > >>>>>>>>>>>>> agrieve@chromium.org
> >> > > > >>>>>>>>>>>>>>>>>> wrote:
> >> > > > >>>>>>>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>>>>>>> Michal's attending hackathons for the week, and
> >> I'm
> >> > > > >>>>>> not
> >> > > > >>>>>>> sure
> >> > > > >>>>>>>>> we
> >> > > > >>>>>>>>>>>>> need
> >> > > > >>>>>>>>>>>>>>>>> to
> >> > > > >>>>>>>>>>>>>>>>> do
> >> > > > >>>>>>>>>>>>>>>>>> a hang-out for this, as I think we really are
> >> quite
> >> > > > >>>>>> close
> >> > > > >>>>>>> to
> >> > > > >>>>>>>>>>>>>> resolving
> >> > > > >>>>>>>>>>>>>>>>>> this. I'd really like to resolve this ASAP so
> >>that
> >> > we
> >> > > > >>>>>>> don't
> >> > > > >>>>>>>>> need
> >> > > > >>>>>>>>>>> to
> >> > > > >>>>>>>>>>>>>>>>> have
> >> > > > >>>>>>>>>>>>>>>>> a
> >> > > > >>>>>>>>>>>>>>>>>> code-freeze for this release.
> >> > > > >>>>>>>>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>>>>>>> Here's a proposal:
> >> > > > >>>>>>>>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>>>>>>> Cordova repositories have three main branches:
> >> > > > >>>>>>>>>>>>>>>>>> 1. stable
> >> > > > >>>>>>>>>>>>>>>>>> 2. next
> >> > > > >>>>>>>>>>>>>>>>>> 3. dev
> >> > > > >>>>>>>>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>>>>>>> Topic branches also exist for collaborating on
> >> > > > >>>>>> features,
> >> > > > >>>>>>> or
> >> > > > >>>>>>>>> for
> >> > > > >>>>>>>>>>>>>>>>> code-review
> >> > > > >>>>>>>>>>>>>>>>>> purposes.
> >> > > > >>>>>>>>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>>>>>>> There is *no* master branch, so that
> >> > community-driven
> >> > > > >>>>>> pull
> >> > > > >>>>>>>>>>> requests
> >> > > > >>>>>>>>>>>>>>>>> will
> >> > > > >>>>>>>>>>>>>>>>> be
> >> > > > >>>>>>>>>>>>>>>>>> forced to think about which branch to request
> >> > against.
> >> > > > >>>>>>>>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>>>>>>> 1. The "stable" branch.
> >> > > > >>>>>>>>>>>>>>>>>> - Sits at the latest stable release of cordova
> >> > > > >>>>>>>>>>>>>>>>>> - No one ever commits to the "stable" branch.
> >>It
> >> > > > >>>>>> exists
> >> > > > >>>>>>> only
> >> > > > >>>>>>>>> as
> >> > > > >>>>>>>>>> a
> >> > > > >>>>>>>>>>>>>>>>>> short-cut for checking out the latest stable
> >>tag.
> >> > > > >>>>>>>>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>>>>>>> 2. The "next" branch.
> >> > > > >>>>>>>>>>>>>>>>>> - This branch exists only when in the process
> >>of
> >> > > > >>>>>> doing a
> >> > > > >>>>>>>>>> release.
> >> > > > >>>>>>>>>>>>>>>>>> - All tags (both stable and RC) are done on
> >>this
> >> > > > >>>>>> branch.
> >> > > > >>>>>>>>>>>>>>>>>> - When a stable tag is done:
> >> > > > >>>>>>>>>>>>>>>>>> - The existing "stable" branch is deleted
> >> > > > >>>>>>>>>>>>>>>>>> - A new "stable" branch is created from
> >>"next".
> >> > > > >>>>>>>>>>>>>>>>>> - The "next" branch is deleted.
> >> > > > >>>>>>>>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>>>>>>> 3. The "dev" branch.
> >> > > > >>>>>>>>>>>>>>>>>> - This is where all commits are done
> >> > > > >>>>>>>>>>>>>>>>>> - This is where topic-branches are merged into.
> >> > > > >>>>>>>>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>>>>>>> Cutting a release:
> >> > > > >>>>>>>>>>>>>>>>>> 1. Create "next" from the HEAD of "dev"
> >> > > > >>>>>>>>>>>>>>>>>> 2. Test test test!
> >> > > > >>>>>>>>>>>>>>>>>> 3. Fix bugs by committing them to "dev" and
> >>then
> >> > > > >>>>>>>>> cherry-picking
> >> > > > >>>>>>>>>>>>> them
> >> > > > >>>>>>>>>>>>>>>>> into
> >> > > > >>>>>>>>>>>>>>>>>> "next"
> >> > > > >>>>>>>>>>>>>>>>>> 4. Tag release candidate
> >> > > > >>>>>>>>>>>>>>>>>> 5. Repeat steps 2-4 as necessary
> >> > > > >>>>>>>>>>>>>>>>>> 6. Tag the release
> >> > > > >>>>>>>>>>>>>>>>>> 7. Create distribution .zip file
> >> > > > >>>>>>>>>>>>>>>>>> 8. Test one last time using the dist files
> >> > > > >>>>>>>>>>>>>>>>>> 9. Delete "stable"
> >> > > > >>>>>>>>>>>>>>>>>> 10. Create a new "stable" by branching from the
> >> HEAD
> >> > > > >>>>>> of
> >> > > > >>>>>>>> "next"
> >> > > > >>>>>>>>>>>>>>>>>> 11. Delete the "next" branch
> >> > > > >>>>>>>>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>>>>>>> On Wed, Jan 16, 2013 at 10:34 AM, Michal Mocny
> >><
> >> > > > >>>>>>>>>>>>> mmocny@chromium.org>
> >> > > > >>>>>>>>>>>>>>>>>> wrote:
> >> > > > >>>>>>>>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>>>>>>>> Just going to throw out one of my personal
> >> > > > >>>>>> requirements
> >> > > > >>>>>>> for
> >> > > > >>>>>>>>>>>>>> whatever
> >> > > > >>>>>>>>>>>>>>>>>>> proposal we come up with, so it doesn't get
> >>lost:
> >> > > > >>>>>>>>>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>>>>>>>> * Feature branches are great for feature work
> >> > and/or
> >> > > > >>>>>>> large
> >> > > > >>>>>>>>>>>>> sweeping
> >> > > > >>>>>>>>>>>>>>>>>>> changes, as are JIRA bugs for tracking them,
> >>but
> >> > > > >>>>>> cordova
> >> > > > >>>>>>>> has
> >> > > > >>>>>>>>>> many
> >> > > > >>>>>>>>>>>>>>>>> many
> >> > > > >>>>>>>>>>>>>>>>>>> trivial issues that could be fixed with
> >> "drive-by"
> >> > > > >>>>>>> patches
> >> > > > >>>>>>>>> that
> >> > > > >>>>>>>>>>>>>>>>> require
> >> > > > >>>>>>>>>>>>>>>>>> as
> >> > > > >>>>>>>>>>>>>>>>>>> little friction to commit as possible.
> >> > > > >>>>>>>>>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>>>>>>>> On Tue, Jan 15, 2013 at 3:05 PM, Marcel
> >>Kinard <
> >> > > > >>>>>>>>>>>>> cmarcelk@gmail.com
> >> > > > >>>>>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>>>>>>> wrote:
> >> > > > >>>>>>>>>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>>>>>>>>> How about if there is a specific straw man
> >> > proposal
> >> > > > >>>>>> at
> >> > > > >>>>>>> the
> >> > > > >>>>>>>>>>>>>>>>> beginning
> >> > > > >>>>>>>>>>>>>>>>> of
> >> > > > >>>>>>>>>>>>>>>>>>>> the face-time? Then the folks that are in
> >> > agreement
> >> > > > >>>>>>> won't
> >> > > > >>>>>>>>> need
> >> > > > >>>>>>>>>>>>> to
> >> > > > >>>>>>>>>>>>>>>>> say
> >> > > > >>>>>>>>>>>>>>>>>>>> anything ;-)
> >> > > > >>>>>>>>>>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>>>>>>>>> Seriously, making adjustments to something
> >> > tangible
> >> > > > >>>>>> is
> >> > > > >>>>>>>>> easier
> >> > > > >>>>>>>>>>>>>> than
> >> > > > >>>>>>>>>>>>>>>>>>>> instantiating it from scratch. A volunteer
> >>for a
> >> > > > >>>>>> very
> >> > > > >>>>>>>> simple
> >> > > > >>>>>>>>>>>>>>>>> writeup
> >> > > > >>>>>>>>>>>>>>>>> on
> >> > > > >>>>>>>>>>>>>>>>>>> the
> >> > > > >>>>>>>>>>>>>>>>>>>> wiki?
> >> > > > >>>>>>>>>>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>>>>>>>>> -- Marcel Kinard
> >> > > > >>>>>>>>>>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>>>>>>>>> On 1/14/2013 10:06 PM, Michal Mocny wrote:
> >> > > > >>>>>>>>>>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>>>>>>>>>> Okay gentlemen, I think there have been
> >> countless
> >> > > > >>>>>> good
> >> > > > >>>>>>>>> points
> >> > > > >>>>>>>>>>>>>>>>> made
> >> > > > >>>>>>>>>>>>>>>>>> from
> >> > > > >>>>>>>>>>>>>>>>>>>>> all
> >> > > > >>>>>>>>>>>>>>>>>>>>> parties, but also some bike-shedding.
> >> > > > >>>>>>>>>>>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>>>>>>>>>> Perhaps it is time to schedule some
> >>face-time
> >> to
> >> > > > >>>>>> better
> >> > > > >>>>>>>>>>>>>>>>> articulate
> >> > > > >>>>>>>>>>>>>>>>>> some
> >> > > > >>>>>>>>>>>>>>>>>>> of
> >> > > > >>>>>>>>>>>>>>>>>>>>> the finer points, and to help come to some
> >> > > > >>>>>> consensus?
> >> > > > >>>>>>>>>>>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>>>>>>>>>> -Michal
> >> > > > >>>>>>>>>>>>>
> >> > > > >>>>>>>>>>>>
> >> > > > >>>>>>>>>>>
> >> > > > >>>>>>>>>>
> >> > > > >>>>>>>>>>
> >> > > > >>>>>>>>>>
> >> > > > >>>>>>>>>> --
> >> > > > >>>>>>>>>> @purplecabbage
> >> > > > >>>>>>>>>> risingj.com
> >> > > > >>>>>>>>>>
> >> > > > >>>>>>>>>
> >> > > > >>>>>>>>
> >> > > > >>>>>>>
> >> > > > >>>>>>>
> >> > > > >>>>>>>
> >> > > > >>>>>>> --
> >> > > > >>>>>>> @purplecabbage
> >> > > > >>>>>>> risingj.com
> >> > > > >>>>>>>
> >> > > > >>>>>>
> >> > > > >>>>>
> >> > > > >>>>>
> >> > > > >>>>
> >> > > > >>>
> >> > > > >>>
> >> > > > >>> --
> >> > > > >>> @purplecabbage
> >> > > > >>> risingj.com
> >> > > > >>
> >> > > > >>
> >> > > >
> >> > > >
> >> > >
> >> >
> >>
>
>
Re: too long to package a release?
Posted by Filip Maj <fi...@adobe.com>.
I noticed on iOS the commits going into next are mirrored on master.
For Android that was not done.
What is the correct process?
On 2/20/13 10:12 AM, "Michal Mocny" <mm...@chromium.org> wrote:
>oooo I didn't know that. Thanks!
>
>
>On Wed, Feb 20, 2013 at 1:10 PM, Becky Gibson
><gi...@gmail.com>wrote:
>
>> Thank you, Michael! I do usually go a git push --dry-run to check that
>>I
>> am pushing what I expect but I'll try the diff as well.
>>
>>
>> On Wed, Feb 20, 2013 at 1:07 PM, Michal Mocny <mm...@chromium.org>
>>wrote:
>>
>> > So there is also http://wiki.apache.org/cordova/CuttingReleases which
>> may
>> > be useful (esp Taggin section).
>> >
>> > As far as the confusion with the two branch names: "topic_branch" is
>>your
>> > local working branch for a bugfix/feature, and "to_be_merged" is
>>really
>> > "temporary_new_name_for_a_branch_to_do_rebase_in". I usually skip
>>that
>> > step and take the risk or rebasing in topic_branch (aside: this may
>> > negatively affect diffs if you push updates for a
>>review-edit-re-review
>> > cycle -- but this isn't an issue for cordova).
>> >
>> > Do not checkout 'next' into your master branch. Update your local
>> branches
>> > to include the remote next branch (with 'git pull apache' with no
>>branch)
>> > then you can switch to the next branch locally, apply your patch
>>there,
>> and
>> > push to that remote branch directly. Later, merge that commit into
>> master
>> > locally, and push that.
>> >
>> > Do not push to apache next from your local master, or else you will
>>push
>> > all the changes.
>> >
>> > I agree, this is a little confusing, but after a few practice runs it
>> > should be easy to figure out. You should probably also check what
>>would
>> be
>> > pushed with 'git diff apache/[target-branch]' or tag on --stat to
>>that to
>> > just see that files that would signal a quick "uh-oh".
>> >
>> > I'll work to update the wiki later today, and likely others will have
>> more
>> > tips on how to make sure we don't make mistakes.
>> >
>> > -Michal
>> >
>> >
>> >
>> > On Wed, Feb 20, 2013 at 12:42 PM, Becky Gibson <gibson.becky@gmail.com
>> > >wrote:
>> >
>> > > Can someone please provide a "git cordova release process for
>>dummies"
>> > > example to make sure I do the release commits and merges properly
>>(the
>> > > committerWorkflow example didn't help me as I didn't understand the
>> > > topic_branch and to_be_merged distinction)
>> > >
>> > > At any rate, can I do a git checkout apache next into my "master"
>> branch?
>> > > Then I can checkout my working_branch, rebase master (which
>>contains
>> > the
>> > > next code) checkout master, merge my fix and push apache next.
>> > > git checkout apache next
>> > > git checkout working_branch_with_fix
>> > > git rebase master
>> > > git checkout master
>> > > git merge working_branch_with_fix
>> > > git push apache next
>> > >
>> > > and then repeat this for apache master with the possibility of
>>needing
>> to
>> > > use -ff when I merge. Am I on the right track?
>> > >
>> > > humbled by git,
>> > > -becky
>> > >
>> > > On Fri, Feb 8, 2013 at 5:22 PM, Marcel Kinard <cm...@gmail.com>
>> > wrote:
>> > >
>> > > > Nice! Thanks, Andrew!
>> > > >
>> > > > -- Marcel Kinard
>> > > >
>> > > > On Feb 7, 2013, at 2:59 PM, Andrew Grieve <ag...@chromium.org>
>> > wrote:
>> > > >
>> > > > > The doc's not up-to-date, but I think we ended on consensus for
>>the
>> > > code
>> > > > > version. I've taken a stab at updating the wiki pages:
>> > > > >
>> > > > > http://wiki.apache.org/cordova/CordovaAndGit -- Added the idea
>>of
>> > > > having
>> > > > > both a master and a next branch
>> > > > > http://wiki.apache.org/cordova/CommitterWorkflow -- Added
>>Jesse's
>> > > > version
>> > > > > of the "which branch - in code"
>> > > > > http://wiki.apache.org/cordova/CuttingReleases -- Changed
>>tagging
>> > > > > instructions to refer to the "next" branch
>> > > > >
>> > > > >
>> > > > > On Thu, Feb 7, 2013 at 1:26 PM, Marcel Kinard
>><cm...@gmail.com>
>> > > > wrote:
>> > > > >
>> > > > >> With 2.5 starting, it appears time to poke this thread.
>> > > > >>
>> > > > >> - Is the Google doc refreshed with the latest consensus?
>> > > > >> - If so, should the Google doc be transferred to a wiki page?
>> > > > >> - Have the necessary branches been created?
>> > > > >> - Are we all in the boat, and understand how to row this beast?
>> > > > >>
>> > > > >> -- Marcel Kinard
>> > > > >>
>> > > > >> On Jan 24, 2013, at 5:14 PM, Jesse <pu...@gmail.com>
>> wrote:
>> > > > >>
>> > > > >>> Nice Shaz, but I was hoping it was a github style network
>> > > visualization
>> > > > >>> that included a few versions worth of merges.
>> > > > >>> Who wants to draw that?
>> > > > >>>
>> > > > >>> On Thu, Jan 24, 2013 at 2:05 PM, Shazron <sh...@gmail.com>
>> > wrote:
>> > > > >>>
>> > > > >>>> Inline image got mangled, here it is linked:
>>http://cl.ly/MOrD
>> > > > >>>>
>> > > > >>>>
>> > > > >>>> On Thu, Jan 24, 2013 at 1:39 PM, Shazron <sh...@gmail.com>
>> > wrote:
>> > > > >>>>
>> > > > >>>>> Thanks for the pseudocode Andrew, seems simpler to
>>understand
>> ;)
>> > > > >> Jesse's
>> > > > >>>>> re-factor makes it even easier. Here's my contrib for those
>> more
>> > > > >> visually
>> > > > >>>>> inclined:
>> > > > >>>>>
>> > > > >>>>>
>> > > > >>>>> [image: Inline image 2]
>> > > > >>>>>
>> > > > >>>>>
>> > > > >>>>> On Thu, Jan 24, 2013 at 1:29 PM, Andrew Grieve <
>> > > agrieve@chromium.org
>> > > > >>> wrote:
>> > > > >>>>>
>> > > > >>>>>> Nice! even simpler. :)
>> > > > >>>>>>
>> > > > >>>>>>
>> > > > >>>>>> On Thu, Jan 24, 2013 at 3:44 PM, Jesse <
>> purplecabbage@gmail.com
>> > >
>> > > > >> wrote:
>> > > > >>>>>>
>> > > > >>>>>>> Thanks for clarifying Andrew. et al, I guess I was
>> > > > mis-understanding
>> > > > >>>>>> some
>> > > > >>>>>>> of the earlier discussion around naming stuff.
>> > > > >>>>>>>
>> > > > >>>>>>> So everything is going to master all the time, and we only
>> care
>> > > > about
>> > > > >>>>>>> 'next' if we are inReleaseMode and it is a bug fix?
>> > > > >>>>>>>
>> > > > >>>>>>> if(inReleaseMode && isBugFix) {
>> > > > >>>>>>> commitToBranch('next');
>> > > > >>>>>>> mergeBranch('next').into('master');
>> > > > >>>>>>> }
>> > > > >>>>>>> else {
>> > > > >>>>>>> commitToBranch('master');
>> > > > >>>>>>> }
>> > > > >>>>>>>
>> > > > >>>>>>>
>> > > > >>>>>>>
>> > > > >>>>>>>
>> > > > >>>>>>>
>> > > > >>>>>>> On Thu, Jan 24, 2013 at 12:29 PM, Andrew Grieve <
>> > > > >> agrieve@chromium.org
>> > > > >>>>>>>> wrote:
>> > > > >>>>>>>
>> > > > >>>>>>>> Just to clarify - there should be *no* using of the git
>> > > > >>>>>> cherry-picking
>> > > > >>>>>>>> command, only git merge.
>> > > > >>>>>>>>
>> > > > >>>>>>>> Jesse - not sure what you're referring to with "branch
>>must
>> be
>> > > > named
>> > > > >>>>>> x".
>> > > > >>>>>>>> The latest revision of the proposal has only two
>>branches:
>> > > master
>> > > > >> and
>> > > > >>>>>>> next.
>> > > > >>>>>>>> Do you mean you don't like the name "next"?
>> > > > >>>>>>>>
>> > > > >>>>>>>> Maybe the proposal will seem simpler if put in the form
>>of
>> > code
>> > > :)
>> > > > >>>>>>>>
>> > > > >>>>>>>> if (!inReleaseMode) {
>> > > > >>>>>>>> commitToBranch('master');
>> > > > >>>>>>>> } else {
>> > > > >>>>>>>> if (isBugFix) {
>> > > > >>>>>>>> commitToBranch('next');
>> > > > >>>>>>>> mergeBranch('next').into('master');
>> > > > >>>>>>>> } else {
>> > > > >>>>>>>> commitToBranch('master');
>> > > > >>>>>>>> }
>> > > > >>>>>>>> }
>> > > > >>>>>>>>
>> > > > >>>>>>>>
>> > > > >>>>>>>> On Thu, Jan 24, 2013 at 3:06 PM, Braden Shepherdson <
>> > > > >>>>>> braden@chromium.org
>> > > > >>>>>>>>> wrote:
>> > > > >>>>>>>>
>> > > > >>>>>>>>> Most of the time the flow will be unchanged: push to
>> master.
>> > > > >>>>>> Tagging
>> > > > >>>>>>>> things
>> > > > >>>>>>>>> we already know how to do; that doesn't change.
>> > > > >>>>>>>>>
>> > > > >>>>>>>>> The only new flow for most people is cherrypicking bug
>> fixes
>> > > from
>> > > > >>>>>>> master
>> > > > >>>>>>>> to
>> > > > >>>>>>>>> next, which we can give examples of. Plus that could
>>remain
>> > the
>> > > > >>>>>>>>> responsibility of the main platform maintainers, who are
>> > doing
>> > > > the
>> > > > >>>>>>>> tagging.
>> > > > >>>>>>>>>
>> > > > >>>>>>>>> Braden
>> > > > >>>>>>>>>
>> > > > >>>>>>>>>
>> > > > >>>>>>>>> On Thu, Jan 24, 2013 at 2:56 PM, Jesse <
>> > > purplecabbage@gmail.com>
>> > > > >>>>>>> wrote:
>> > > > >>>>>>>>>
>> > > > >>>>>>>>>> On Thu, Jan 24, 2013 at 11:09 AM, Braden Shepherdson <
>> > > > >>>>>>>>> braden@chromium.org
>> > > > >>>>>>>>>>> wrote:
>> > > > >>>>>>>>>>
>> > > > >>>>>>>>>>> The founding goal we're trying to accomplish here is
>>that
>> > we
>> > > > >>>>>> don't
>> > > > >>>>>>>> want
>> > > > >>>>>>>>>>> everyone sitting on changes to be in the next version
>> while
>> > > we
>> > > > >>>>>> use
>> > > > >>>>>>>>> master
>> > > > >>>>>>>>>>> to prep a release.
>> > > > >>>>>>>>>>>
>> > > > >>>>>>>>>>> I don't think having one branch for prepping the
>>release
>> > and
>> > > > >>>>>>> another
>> > > > >>>>>>>>> for
>> > > > >>>>>>>>>>> main development is a lot of bureaucracy.
>> > > > >>>>>>>>>>>
>> > > > >>>>>>>>>>
>> > > > >>>>>>>>>> It is not, the 'branch must be named x' is mainly
>>where I
>> > have
>> > > > >>>>>>>> concerns.
>> > > > >>>>>>>>>> Really I just want things simple.
>> > > > >>>>>>>>>>
>> > > > >>>>>>>>>>
>> > > > >>>>>>>>>>>
>> > > > >>>>>>>>>>>
>> > > > >>>>>>>>>>> On Thu, Jan 24, 2013 at 1:57 PM, Jesse MacFadyen <
>> > > > >>>>>>>>>> purplecabbage@gmail.com
>> > > > >>>>>>>>>>>> wrote:
>> > > > >>>>>>>>>>>
>> > > > >>>>>>>>>>>> I have been quietly listening on this thread, but
>> thought
>> > I
>> > > > >>>>>>> should
>> > > > >>>>>>>> at
>> > > > >>>>>>>>>>>> least share my opinion.
>> > > > >>>>>>>>>>>>
>> > > > >>>>>>>>>>>> I don't think adding contribution rules helps anyone.
>> Git
>> > is
>> > > > >>>>>>>>>>>> complicated enough as it is, and this just all seems
>> like
>> > > > >>>>>>>>> bureaucracy.
>> > > > >>>>>>>>>>>>
>> > > > >>>>>>>>>>>> I think master should always contain the latest
>>stable
>> > code,
>> > > > >>>>>> and
>> > > > >>>>>>> be
>> > > > >>>>>>>>>>>> periodically tagged with rc's and versions.
>> > > > >>>>>>>>>>>> All work should be done in personal forks and feature
>> > > > >>>>>> branches.
>> > > > >>>>>>>>>>>> If the latest tag of master is an rc, then we should
>> only
>> > be
>> > > > >>>>>>>> merging
>> > > > >>>>>>>>>>>> bugfixes, until the release.
>> > > > >>>>>>>>>>>> Immediately after tagging a version we decide which
>> > feature
>> > > > >>>>>>>> branches
>> > > > >>>>>>>>>>>> and pull requests to pull in, and go for it.
>> > > > >>>>>>>>>>>>
>> > > > >>>>>>>>>>>> I don't think this is much different from what we
>>have,
>> > but
>> > > I
>> > > > >>>>>>> think
>> > > > >>>>>>>>>>>> that is good.
>> > > > >>>>>>>>>>>> The suggestions thus far, while interesting, don't
>> > increase
>> > > > >>>>>> our
>> > > > >>>>>>>>>>>> velocity in my opinion. Also, I can also pretty much
>> > > guaranty
>> > > > >>>>>>> I'll
>> > > > >>>>>>>>>>>> screw it up for the next 3-4 versions. ( because I'm
>> dumb
>> > )
>> > > > >>>>>>>>>>>>
>> > > > >>>>>>>>>>>> Cheers,
>> > > > >>>>>>>>>>>> Jesse
>> > > > >>>>>>>>>>>>
>> > > > >>>>>>>>>>>>
>> > > > >>>>>>>>>>>>
>> > > > >>>>>>>>>>>> On 2013-01-24, at 5:53 AM, Andrew Grieve <
>> > > > >>>>>> agrieve@chromium.org>
>> > > > >>>>>>>>> wrote:
>> > > > >>>>>>>>>>>>
>> > > > >>>>>>>>>>>> On Wed, Jan 23, 2013 at 4:58 PM, Michael Brooks <
>> > > > >>>>>>>>>>> michael@michaelbrooks.ca
>> > > > >>>>>>>>>>>>> wrote:
>> > > > >>>>>>>>>>>>
>> > > > >>>>>>>>>>>>> Before we move forward, I have a few questions about
>> the
>> > > > >>>>>> "no
>> > > > >>>>>>>>> master"
>> > > > >>>>>>>>>>>>> approach.
>> > > > >>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>> There is *no* master branch, so that
>>community-driven
>> > pull
>> > > > >>>>>>>> requests
>> > > > >>>>>>>>>>> will
>> > > > >>>>>>>>>>>> be
>> > > > >>>>>>>>>>>>>> forced to think about which branch to request
>>against.
>> > > > >>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>> - Andrew, can you cite other projects that do not
>>use a
>> > > > >>>>>> master
>> > > > >>>>>>>>>> branch?
>> > > > >>>>>>>>>>>> This project is my first time using git / github, so
>>I
>> > don't
>> > > > >>>>>> have
>> > > > >>>>>>>>> much
>> > > > >>>>>>>>>> to
>> > > > >>>>>>>>>>>> draw from. I was going off of others' suggestions on
>> this
>> > > > >>>>>> thread
>> > > > >>>>>>>>> when I
>> > > > >>>>>>>>>>>> proposed the names.
>> > > > >>>>>>>>>>>>
>> > > > >>>>>>>>>>>>
>> > > > >>>>>>>>>>>>> - On Github, you must have a default branch. If not
>> > > > >>>>>> master, it
>> > > > >>>>>>>> must
>> > > > >>>>>>>>>> be
>> > > > >>>>>>>>>>>>> something else. So, users are not forced to think
>>about
>> > the
>> > > > >>>>>>>> branch
>> > > > >>>>>>>>> to
>> > > > >>>>>>>>>>>> send
>> > > > >>>>>>>>>>>>> a pull request again... they will likely just use
>>the
>> > > > >>>>>> default.
>> > > > >>>>>>>>>>>>
>> > > > >>>>>>>>>>>> Hmm, good point. The goal is to get people
>>downloading
>> > > > >>>>>> Cordova
>> > > > >>>>>>> for
>> > > > >>>>>>>>> use
>> > > > >>>>>>>>>> to
>> > > > >>>>>>>>>>>> end up with Stable, and for developers to send pull
>> > requests
>> > > > >>>>>>>> against
>> > > > >>>>>>>>>> dev.
>> > > > >>>>>>>>>>>> With a forced default branch, I don't think we can
>> > > accomplish
>> > > > >>>>>>> this.
>> > > > >>>>>>>>>>>>
>> > > > >>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>> - Why is the "stable" branch not just "master"?
>> > > > >>>>>>>>>>>>
>> > > > >>>>>>>>>>>> My thinking was that it's not obvious whether Master
>>==
>> > > > >>>>>> bleeding
>> > > > >>>>>>>>> edge,
>> > > > >>>>>>>>>> or
>> > > > >>>>>>>>>>>> Master == Stable version. Using the names "dev" and
>> > "stable"
>> > > > >>>>>>> makes
>> > > > >>>>>>>>> it a
>> > > > >>>>>>>>>>> bit
>> > > > >>>>>>>>>>>> clear.
>> > > > >>>>>>>>>>>>
>> > > > >>>>>>>>>>>>
>> > > > >>>>>>>>>>>>
>> > > > >>>>>>>>>>>> So... If github forces us to have a default branch,
>>I'm
>> > > > >>>>>> thinking
>> > > > >>>>>>>> that
>> > > > >>>>>>>>>>>> having users send pull requests against "dev" is more
>> > > > >>>>>> valuable
>> > > > >>>>>>> than
>> > > > >>>>>>>>>>> having
>> > > > >>>>>>>>>>>> people download the latest "stable" by default. If
>> people
>> > > are
>> > > > >>>>>>>> pulling
>> > > > >>>>>>>>>>> code
>> > > > >>>>>>>>>>>> from github rather than from our release .zip files,
>> then
>> > > > >>>>>> it's
>> > > > >>>>>>>> likely
>> > > > >>>>>>>>>>> they
>> > > > >>>>>>>>>>>> want to hack on it anyways, or that they want the dev
>> > > > >>>>>> version to
>> > > > >>>>>>>> see
>> > > > >>>>>>>>> if
>> > > > >>>>>>>>>>>> bugs are fixed.
>> > > > >>>>>>>>>>>>
>> > > > >>>>>>>>>>>> Soo.... Here's version #3! If anyone can think of
>>how to
>> > > > >>>>>> keep the
>> > > > >>>>>>>>> three
>> > > > >>>>>>>>>>>> branches while addressing being forced to have a
>>default
>> > > > >>>>>> branch,
>> > > > >>>>>>>> feel
>> > > > >>>>>>>>>>> free
>> > > > >>>>>>>>>>>> to speak up! :)
>> > > > >>>>>>>>>>>>
>> > > > >>>>>>>>>>>>
>> > > > >>>>>>>>>>>> Cordova repositories have two main branches:
>> > > > >>>>>>>>>>>> 1. master
>> > > > >>>>>>>>>>>> 2. next
>> > > > >>>>>>>>>>>>
>> > > > >>>>>>>>>>>> Topic branches exist for collaborating on features,
>>or
>> for
>> > > > >>>>>>>>> code-review
>> > > > >>>>>>>>>>>> purposes.
>> > > > >>>>>>>>>>>>
>> > > > >>>>>>>>>>>> Cordova uses tags to label releases.
>> > > > >>>>>>>>>>>> - Each release candidate has a tag. e.g. "2.2.0rc1"
>> > > > >>>>>>>>>>>> - Each release has a tag. e.g. "2.2.0"
>> > > > >>>>>>>>>>>> - The "latest" tag points to the last stable release
>> (this
>> > > > >>>>>>> follows
>> > > > >>>>>>>>> npm
>> > > > >>>>>>>>>>>> conventions)
>> > > > >>>>>>>>>>>>
>> > > > >>>>>>>>>>>>
>> > > > >>>>>>>>>>>> 1. The "next" branch.
>> > > > >>>>>>>>>>>> - This branch is used only when in the process of
>>doing
>> a
>> > > > >>>>>>> release.
>> > > > >>>>>>>>>>>> - All tags are created from this branch.
>> > > > >>>>>>>>>>>> - All release-candidate bug-fixes are done on this
>> branch.
>> > > > >>>>>>>>>>>>
>> > > > >>>>>>>>>>>> 2. The "master" branch.
>> > > > >>>>>>>>>>>> - When not in the release-process, all commits are
>>made
>> > here
>> > > > >>>>>>>>>>>> - When in the release-process, all non-bugfix commits
>> are
>> > > > >>>>>> made
>> > > > >>>>>>>> here
>> > > > >>>>>>>>>>>> - This is where topic-branches are merged into.
>> > > > >>>>>>>>>>>>
>> > > > >>>>>>>>>>>> Cutting a release:
>> > > > >>>>>>>>>>>> 1. git checkout next && git merge --ff-only master
>> > > > >>>>>>>>>>>> 2. Test test test!
>> > > > >>>>>>>>>>>> 3. Fix bugs by committing them directly to "next" and
>> then
>> > > > >>>>>> doing
>> > > > >>>>>>> a
>> > > > >>>>>>>>>> non-ff
>> > > > >>>>>>>>>>>> merge of next into master
>> > > > >>>>>>>>>>>> 4. Tag release candidate
>> > > > >>>>>>>>>>>> 5. Repeat steps 2-4 as necessary
>> > > > >>>>>>>>>>>> 6. Tag the release (both by version and by updating
>>the
>> > > > >>>>>> "latest"
>> > > > >>>>>>>> tag)
>> > > > >>>>>>>>>>>> 7. Create distribution .zip file
>> > > > >>>>>>>>>>>> 8. Test one last time using the dist files
>> > > > >>>>>>>>>>>>
>> > > > >>>>>>>>>>>>
>> > > > >>>>>>>>>>>>
>> > > > >>>>>>>>>>>>
>> > > > >>>>>>>>>>>>
>> > > > >>>>>>>>>>>>
>> > > > >>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>> Thanks,
>> > > > >>>>>>>>>>>>> Michael
>> > > > >>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>> On Wed, Jan 23, 2013 at 11:25 AM, Brian LeRoux <
>> > b@brian.io
>> > > > >>>>>>>
>> > > > >>>>>>>> wrote:
>> > > > >>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>> I'm liking it. Start in 2.5?
>> > > > >>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>> On Wed, Jan 23, 2013 at 1:19 PM, Filip Maj <
>> > fil@adobe.com
>> > > > >>>>>>>
>> > > > >>>>>>>> wrote:
>> > > > >>>>>>>>>>>>>>> Looks great Andrew!
>> > > > >>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>> If everyone's on board, how are we going to test
>>run
>> > > > >>>>>> this?
>> > > > >>>>>>>> Flip a
>> > > > >>>>>>>>>>>>> switch
>> > > > >>>>>>>>>>>>>>> at a certain point, give it a shot with one repo
>>for
>> > one
>> > > > >>>>>> RC?
>> > > > >>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>> On 1/22/13 12:29 PM, "Andrew Grieve" <
>> > > > >>>>>> agrieve@chromium.org>
>> > > > >>>>>>>>> wrote:
>> > > > >>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>> Braden, you're right. I've now done some local
>> playing
>> > > > >>>>>>> around
>> > > > >>>>>>>> in
>> > > > >>>>>>>>>>> git,
>> > > > >>>>>>>>>>>>> and
>> > > > >>>>>>>>>>>>>>>> have an updated proposal that uses merges
>>instead of
>> > > > >>>>>>> deleting
>> > > > >>>>>>>>>>>> branches.
>> > > > >>>>>>>>>>>>>>>> PTAL:
>> > > > >>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>> Cordova repositories have three main branches:
>> > > > >>>>>>>>>>>>>>>> 1. stable
>> > > > >>>>>>>>>>>>>>>> 2. next
>> > > > >>>>>>>>>>>>>>>> 3. dev
>> > > > >>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>> Topic branches also exist for collaborating on
>> > > > >>>>>> features, or
>> > > > >>>>>>>> for
>> > > > >>>>>>>>>>>>>>>> code-review
>> > > > >>>>>>>>>>>>>>>> purposes.
>> > > > >>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>> There is *no* master branch, so that
>> community-driven
>> > > > >>>>>> pull
>> > > > >>>>>>>>>> requests
>> > > > >>>>>>>>>>>>> will
>> > > > >>>>>>>>>>>>>>>> be
>> > > > >>>>>>>>>>>>>>>> forced to think about which branch to request
>> against.
>> > > > >>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>> 1. The "stable" branch.
>> > > > >>>>>>>>>>>>>>>> - Sits at the latest stable release of cordova
>> > > > >>>>>>>>>>>>>>>> - This changes only when doing fast-forward
>>merges
>> > from
>> > > > >>>>>>> "next"
>> > > > >>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>> 2. The "next" branch.
>> > > > >>>>>>>>>>>>>>>> - This branch is used only when in the process of
>> > doing
>> > > > >>>>>> a
>> > > > >>>>>>>>> release.
>> > > > >>>>>>>>>>>>>>>> - All tags (both stable and RC) are done on this
>> > branch.
>> > > > >>>>>>>>>>>>>>>> - All release-candidate bug-fixes are done on
>>this
>> > > > >>>>>> branch.
>> > > > >>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>> 3. The "dev" branch.
>> > > > >>>>>>>>>>>>>>>> - This is where non-release-candidate commits are
>> done
>> > > > >>>>>>>>>>>>>>>> - This is where topic-branches are merged into.
>> > > > >>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>> Cutting a release:
>> > > > >>>>>>>>>>>>>>>> 1. git checkout next && git merge --ff-only dev
>> > > > >>>>>>>>>>>>>>>> 2. Test test test!
>> > > > >>>>>>>>>>>>>>>> 3. Fix bugs by committing them directly to "next"
>> and
>> > > > >>>>>> then
>> > > > >>>>>>>>> doing a
>> > > > >>>>>>>>>>>>> non-ff
>> > > > >>>>>>>>>>>>>>>> merge of next into dev
>> > > > >>>>>>>>>>>>>>>> 4. Tag release candidate
>> > > > >>>>>>>>>>>>>>>> 5. Repeat steps 2-4 as necessary
>> > > > >>>>>>>>>>>>>>>> 6. Tag the release
>> > > > >>>>>>>>>>>>>>>> 7. Create distribution .zip file
>> > > > >>>>>>>>>>>>>>>> 8. Test one last time using the dist files
>> > > > >>>>>>>>>>>>>>>> 9. git checkout stable && git merge --ff-only
>>next
>> > > > >>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>> On Tue, Jan 22, 2013 at 1:59 PM, Braden
>>Shepherdson
>> > > > >>>>>>>>>>>>>>>> <br...@chromium.org>wrote:
>> > > > >>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>> I think deleting and recreating branches with
>>the
>> > same
>> > > > >>>>>> name
>> > > > >>>>>>>> can
>> > > > >>>>>>>>>>> cause
>> > > > >>>>>>>>>>>>>>>>> badness in git[1] because of remotes. It's not
>> really
>> > > > >>>>>> the
>> > > > >>>>>>>> same
>> > > > >>>>>>>>>>> branch
>> > > > >>>>>>>>>>>>>> in
>> > > > >>>>>>>>>>>>>>>>> terms of commits, and git thinks that your old
>> stable
>> > > > >>>>>> and
>> > > > >>>>>>> the
>> > > > >>>>>>>>> new
>> > > > >>>>>>>>>>>>>> stable
>> > > > >>>>>>>>>>>>>>>>> differ by all of each of their commits. Tags
>>can be
>> > > > >>>>>> moved
>> > > > >>>>>>>>>>>>> arbitrarily,
>> > > > >>>>>>>>>>>>>>>>> so I
>> > > > >>>>>>>>>>>>>>>>> think stable makes sense as a tag. I'm not sure
>> about
>> > > > >>>>>> how
>> > > > >>>>>>>> best
>> > > > >>>>>>>>> to
>> > > > >>>>>>>>>>>>>> handle
>> > > > >>>>>>>>>>>>>>>>> next.
>> > > > >>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>> [1]
>> > > > >>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>
>> > > > >>>>>>>>>>>
>> > > > >>>>>>>>>>
>> > > > >>>>>>>>>
>> > > > >>>>>>>>
>> > > > >>>>>>>
>> > > > >>>>>>
>> > > > >>
>> > > >
>> > >
>> >
>>
>>http://stackoverflow.com/questions/11844581/git-delete-and-recreate-branc
>> > > > >>>>>>>>>>>>>>>>> h
>> > > > >>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>> On Tue, Jan 22, 2013 at 11:31 AM, Andrew Grieve
>><
>> > > > >>>>>>>>>>>>> agrieve@chromium.org
>> > > > >>>>>>>>>>>>>>>>>> wrote:
>> > > > >>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>>> Michal's attending hackathons for the week, and
>> I'm
>> > > > >>>>>> not
>> > > > >>>>>>> sure
>> > > > >>>>>>>>> we
>> > > > >>>>>>>>>>>>> need
>> > > > >>>>>>>>>>>>>>>>> to
>> > > > >>>>>>>>>>>>>>>>> do
>> > > > >>>>>>>>>>>>>>>>>> a hang-out for this, as I think we really are
>> quite
>> > > > >>>>>> close
>> > > > >>>>>>> to
>> > > > >>>>>>>>>>>>>> resolving
>> > > > >>>>>>>>>>>>>>>>>> this. I'd really like to resolve this ASAP so
>>that
>> > we
>> > > > >>>>>>> don't
>> > > > >>>>>>>>> need
>> > > > >>>>>>>>>>> to
>> > > > >>>>>>>>>>>>>>>>> have
>> > > > >>>>>>>>>>>>>>>>> a
>> > > > >>>>>>>>>>>>>>>>>> code-freeze for this release.
>> > > > >>>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>>> Here's a proposal:
>> > > > >>>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>>> Cordova repositories have three main branches:
>> > > > >>>>>>>>>>>>>>>>>> 1. stable
>> > > > >>>>>>>>>>>>>>>>>> 2. next
>> > > > >>>>>>>>>>>>>>>>>> 3. dev
>> > > > >>>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>>> Topic branches also exist for collaborating on
>> > > > >>>>>> features,
>> > > > >>>>>>> or
>> > > > >>>>>>>>> for
>> > > > >>>>>>>>>>>>>>>>> code-review
>> > > > >>>>>>>>>>>>>>>>>> purposes.
>> > > > >>>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>>> There is *no* master branch, so that
>> > community-driven
>> > > > >>>>>> pull
>> > > > >>>>>>>>>>> requests
>> > > > >>>>>>>>>>>>>>>>> will
>> > > > >>>>>>>>>>>>>>>>> be
>> > > > >>>>>>>>>>>>>>>>>> forced to think about which branch to request
>> > against.
>> > > > >>>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>>> 1. The "stable" branch.
>> > > > >>>>>>>>>>>>>>>>>> - Sits at the latest stable release of cordova
>> > > > >>>>>>>>>>>>>>>>>> - No one ever commits to the "stable" branch.
>>It
>> > > > >>>>>> exists
>> > > > >>>>>>> only
>> > > > >>>>>>>>> as
>> > > > >>>>>>>>>> a
>> > > > >>>>>>>>>>>>>>>>>> short-cut for checking out the latest stable
>>tag.
>> > > > >>>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>>> 2. The "next" branch.
>> > > > >>>>>>>>>>>>>>>>>> - This branch exists only when in the process
>>of
>> > > > >>>>>> doing a
>> > > > >>>>>>>>>> release.
>> > > > >>>>>>>>>>>>>>>>>> - All tags (both stable and RC) are done on
>>this
>> > > > >>>>>> branch.
>> > > > >>>>>>>>>>>>>>>>>> - When a stable tag is done:
>> > > > >>>>>>>>>>>>>>>>>> - The existing "stable" branch is deleted
>> > > > >>>>>>>>>>>>>>>>>> - A new "stable" branch is created from
>>"next".
>> > > > >>>>>>>>>>>>>>>>>> - The "next" branch is deleted.
>> > > > >>>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>>> 3. The "dev" branch.
>> > > > >>>>>>>>>>>>>>>>>> - This is where all commits are done
>> > > > >>>>>>>>>>>>>>>>>> - This is where topic-branches are merged into.
>> > > > >>>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>>> Cutting a release:
>> > > > >>>>>>>>>>>>>>>>>> 1. Create "next" from the HEAD of "dev"
>> > > > >>>>>>>>>>>>>>>>>> 2. Test test test!
>> > > > >>>>>>>>>>>>>>>>>> 3. Fix bugs by committing them to "dev" and
>>then
>> > > > >>>>>>>>> cherry-picking
>> > > > >>>>>>>>>>>>> them
>> > > > >>>>>>>>>>>>>>>>> into
>> > > > >>>>>>>>>>>>>>>>>> "next"
>> > > > >>>>>>>>>>>>>>>>>> 4. Tag release candidate
>> > > > >>>>>>>>>>>>>>>>>> 5. Repeat steps 2-4 as necessary
>> > > > >>>>>>>>>>>>>>>>>> 6. Tag the release
>> > > > >>>>>>>>>>>>>>>>>> 7. Create distribution .zip file
>> > > > >>>>>>>>>>>>>>>>>> 8. Test one last time using the dist files
>> > > > >>>>>>>>>>>>>>>>>> 9. Delete "stable"
>> > > > >>>>>>>>>>>>>>>>>> 10. Create a new "stable" by branching from the
>> HEAD
>> > > > >>>>>> of
>> > > > >>>>>>>> "next"
>> > > > >>>>>>>>>>>>>>>>>> 11. Delete the "next" branch
>> > > > >>>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>>> On Wed, Jan 16, 2013 at 10:34 AM, Michal Mocny
>><
>> > > > >>>>>>>>>>>>> mmocny@chromium.org>
>> > > > >>>>>>>>>>>>>>>>>> wrote:
>> > > > >>>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>>>> Just going to throw out one of my personal
>> > > > >>>>>> requirements
>> > > > >>>>>>> for
>> > > > >>>>>>>>>>>>>> whatever
>> > > > >>>>>>>>>>>>>>>>>>> proposal we come up with, so it doesn't get
>>lost:
>> > > > >>>>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>>>> * Feature branches are great for feature work
>> > and/or
>> > > > >>>>>>> large
>> > > > >>>>>>>>>>>>> sweeping
>> > > > >>>>>>>>>>>>>>>>>>> changes, as are JIRA bugs for tracking them,
>>but
>> > > > >>>>>> cordova
>> > > > >>>>>>>> has
>> > > > >>>>>>>>>> many
>> > > > >>>>>>>>>>>>>>>>> many
>> > > > >>>>>>>>>>>>>>>>>>> trivial issues that could be fixed with
>> "drive-by"
>> > > > >>>>>>> patches
>> > > > >>>>>>>>> that
>> > > > >>>>>>>>>>>>>>>>> require
>> > > > >>>>>>>>>>>>>>>>>> as
>> > > > >>>>>>>>>>>>>>>>>>> little friction to commit as possible.
>> > > > >>>>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>>>> On Tue, Jan 15, 2013 at 3:05 PM, Marcel
>>Kinard <
>> > > > >>>>>>>>>>>>> cmarcelk@gmail.com
>> > > > >>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>>> wrote:
>> > > > >>>>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>>>>> How about if there is a specific straw man
>> > proposal
>> > > > >>>>>> at
>> > > > >>>>>>> the
>> > > > >>>>>>>>>>>>>>>>> beginning
>> > > > >>>>>>>>>>>>>>>>> of
>> > > > >>>>>>>>>>>>>>>>>>>> the face-time? Then the folks that are in
>> > agreement
>> > > > >>>>>>> won't
>> > > > >>>>>>>>> need
>> > > > >>>>>>>>>>>>> to
>> > > > >>>>>>>>>>>>>>>>> say
>> > > > >>>>>>>>>>>>>>>>>>>> anything ;-)
>> > > > >>>>>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>>>>> Seriously, making adjustments to something
>> > tangible
>> > > > >>>>>> is
>> > > > >>>>>>>>> easier
>> > > > >>>>>>>>>>>>>> than
>> > > > >>>>>>>>>>>>>>>>>>>> instantiating it from scratch. A volunteer
>>for a
>> > > > >>>>>> very
>> > > > >>>>>>>> simple
>> > > > >>>>>>>>>>>>>>>>> writeup
>> > > > >>>>>>>>>>>>>>>>> on
>> > > > >>>>>>>>>>>>>>>>>>> the
>> > > > >>>>>>>>>>>>>>>>>>>> wiki?
>> > > > >>>>>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>>>>> -- Marcel Kinard
>> > > > >>>>>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>>>>> On 1/14/2013 10:06 PM, Michal Mocny wrote:
>> > > > >>>>>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>>>>>> Okay gentlemen, I think there have been
>> countless
>> > > > >>>>>> good
>> > > > >>>>>>>>> points
>> > > > >>>>>>>>>>>>>>>>> made
>> > > > >>>>>>>>>>>>>>>>>> from
>> > > > >>>>>>>>>>>>>>>>>>>>> all
>> > > > >>>>>>>>>>>>>>>>>>>>> parties, but also some bike-shedding.
>> > > > >>>>>>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>>>>>> Perhaps it is time to schedule some
>>face-time
>> to
>> > > > >>>>>> better
>> > > > >>>>>>>>>>>>>>>>> articulate
>> > > > >>>>>>>>>>>>>>>>>> some
>> > > > >>>>>>>>>>>>>>>>>>> of
>> > > > >>>>>>>>>>>>>>>>>>>>> the finer points, and to help come to some
>> > > > >>>>>> consensus?
>> > > > >>>>>>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>>>>>> -Michal
>> > > > >>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>
>> > > > >>>>>>>>>>>
>> > > > >>>>>>>>>>
>> > > > >>>>>>>>>>
>> > > > >>>>>>>>>>
>> > > > >>>>>>>>>> --
>> > > > >>>>>>>>>> @purplecabbage
>> > > > >>>>>>>>>> risingj.com
>> > > > >>>>>>>>>>
>> > > > >>>>>>>>>
>> > > > >>>>>>>>
>> > > > >>>>>>>
>> > > > >>>>>>>
>> > > > >>>>>>>
>> > > > >>>>>>> --
>> > > > >>>>>>> @purplecabbage
>> > > > >>>>>>> risingj.com
>> > > > >>>>>>>
>> > > > >>>>>>
>> > > > >>>>>
>> > > > >>>>>
>> > > > >>>>
>> > > > >>>
>> > > > >>>
>> > > > >>> --
>> > > > >>> @purplecabbage
>> > > > >>> risingj.com
>> > > > >>
>> > > > >>
>> > > >
>> > > >
>> > >
>> >
>>
Re: too long to package a release?
Posted by Michal Mocny <mm...@chromium.org>.
oooo I didn't know that. Thanks!
On Wed, Feb 20, 2013 at 1:10 PM, Becky Gibson <gi...@gmail.com>wrote:
> Thank you, Michael! I do usually go a git push --dry-run to check that I
> am pushing what I expect but I'll try the diff as well.
>
>
> On Wed, Feb 20, 2013 at 1:07 PM, Michal Mocny <mm...@chromium.org> wrote:
>
> > So there is also http://wiki.apache.org/cordova/CuttingReleases which
> may
> > be useful (esp Taggin section).
> >
> > As far as the confusion with the two branch names: "topic_branch" is your
> > local working branch for a bugfix/feature, and "to_be_merged" is really
> > "temporary_new_name_for_a_branch_to_do_rebase_in". I usually skip that
> > step and take the risk or rebasing in topic_branch (aside: this may
> > negatively affect diffs if you push updates for a review-edit-re-review
> > cycle -- but this isn't an issue for cordova).
> >
> > Do not checkout 'next' into your master branch. Update your local
> branches
> > to include the remote next branch (with 'git pull apache' with no branch)
> > then you can switch to the next branch locally, apply your patch there,
> and
> > push to that remote branch directly. Later, merge that commit into
> master
> > locally, and push that.
> >
> > Do not push to apache next from your local master, or else you will push
> > all the changes.
> >
> > I agree, this is a little confusing, but after a few practice runs it
> > should be easy to figure out. You should probably also check what would
> be
> > pushed with 'git diff apache/[target-branch]' or tag on --stat to that to
> > just see that files that would signal a quick "uh-oh".
> >
> > I'll work to update the wiki later today, and likely others will have
> more
> > tips on how to make sure we don't make mistakes.
> >
> > -Michal
> >
> >
> >
> > On Wed, Feb 20, 2013 at 12:42 PM, Becky Gibson <gibson.becky@gmail.com
> > >wrote:
> >
> > > Can someone please provide a "git cordova release process for dummies"
> > > example to make sure I do the release commits and merges properly (the
> > > committerWorkflow example didn't help me as I didn't understand the
> > > topic_branch and to_be_merged distinction)
> > >
> > > At any rate, can I do a git checkout apache next into my "master"
> branch?
> > > Then I can checkout my working_branch, rebase master (which contains
> > the
> > > next code) checkout master, merge my fix and push apache next.
> > > git checkout apache next
> > > git checkout working_branch_with_fix
> > > git rebase master
> > > git checkout master
> > > git merge working_branch_with_fix
> > > git push apache next
> > >
> > > and then repeat this for apache master with the possibility of needing
> to
> > > use -ff when I merge. Am I on the right track?
> > >
> > > humbled by git,
> > > -becky
> > >
> > > On Fri, Feb 8, 2013 at 5:22 PM, Marcel Kinard <cm...@gmail.com>
> > wrote:
> > >
> > > > Nice! Thanks, Andrew!
> > > >
> > > > -- Marcel Kinard
> > > >
> > > > On Feb 7, 2013, at 2:59 PM, Andrew Grieve <ag...@chromium.org>
> > wrote:
> > > >
> > > > > The doc's not up-to-date, but I think we ended on consensus for the
> > > code
> > > > > version. I've taken a stab at updating the wiki pages:
> > > > >
> > > > > http://wiki.apache.org/cordova/CordovaAndGit -- Added the idea of
> > > > having
> > > > > both a master and a next branch
> > > > > http://wiki.apache.org/cordova/CommitterWorkflow -- Added Jesse's
> > > > version
> > > > > of the "which branch - in code"
> > > > > http://wiki.apache.org/cordova/CuttingReleases -- Changed tagging
> > > > > instructions to refer to the "next" branch
> > > > >
> > > > >
> > > > > On Thu, Feb 7, 2013 at 1:26 PM, Marcel Kinard <cm...@gmail.com>
> > > > wrote:
> > > > >
> > > > >> With 2.5 starting, it appears time to poke this thread.
> > > > >>
> > > > >> - Is the Google doc refreshed with the latest consensus?
> > > > >> - If so, should the Google doc be transferred to a wiki page?
> > > > >> - Have the necessary branches been created?
> > > > >> - Are we all in the boat, and understand how to row this beast?
> > > > >>
> > > > >> -- Marcel Kinard
> > > > >>
> > > > >> On Jan 24, 2013, at 5:14 PM, Jesse <pu...@gmail.com>
> wrote:
> > > > >>
> > > > >>> Nice Shaz, but I was hoping it was a github style network
> > > visualization
> > > > >>> that included a few versions worth of merges.
> > > > >>> Who wants to draw that?
> > > > >>>
> > > > >>> On Thu, Jan 24, 2013 at 2:05 PM, Shazron <sh...@gmail.com>
> > wrote:
> > > > >>>
> > > > >>>> Inline image got mangled, here it is linked: http://cl.ly/MOrD
> > > > >>>>
> > > > >>>>
> > > > >>>> On Thu, Jan 24, 2013 at 1:39 PM, Shazron <sh...@gmail.com>
> > wrote:
> > > > >>>>
> > > > >>>>> Thanks for the pseudocode Andrew, seems simpler to understand
> ;)
> > > > >> Jesse's
> > > > >>>>> re-factor makes it even easier. Here's my contrib for those
> more
> > > > >> visually
> > > > >>>>> inclined:
> > > > >>>>>
> > > > >>>>>
> > > > >>>>> [image: Inline image 2]
> > > > >>>>>
> > > > >>>>>
> > > > >>>>> On Thu, Jan 24, 2013 at 1:29 PM, Andrew Grieve <
> > > agrieve@chromium.org
> > > > >>> wrote:
> > > > >>>>>
> > > > >>>>>> Nice! even simpler. :)
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>> On Thu, Jan 24, 2013 at 3:44 PM, Jesse <
> purplecabbage@gmail.com
> > >
> > > > >> wrote:
> > > > >>>>>>
> > > > >>>>>>> Thanks for clarifying Andrew. et al, I guess I was
> > > > mis-understanding
> > > > >>>>>> some
> > > > >>>>>>> of the earlier discussion around naming stuff.
> > > > >>>>>>>
> > > > >>>>>>> So everything is going to master all the time, and we only
> care
> > > > about
> > > > >>>>>>> 'next' if we are inReleaseMode and it is a bug fix?
> > > > >>>>>>>
> > > > >>>>>>> if(inReleaseMode && isBugFix) {
> > > > >>>>>>> commitToBranch('next');
> > > > >>>>>>> mergeBranch('next').into('master');
> > > > >>>>>>> }
> > > > >>>>>>> else {
> > > > >>>>>>> commitToBranch('master');
> > > > >>>>>>> }
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>> On Thu, Jan 24, 2013 at 12:29 PM, Andrew Grieve <
> > > > >> agrieve@chromium.org
> > > > >>>>>>>> wrote:
> > > > >>>>>>>
> > > > >>>>>>>> Just to clarify - there should be *no* using of the git
> > > > >>>>>> cherry-picking
> > > > >>>>>>>> command, only git merge.
> > > > >>>>>>>>
> > > > >>>>>>>> Jesse - not sure what you're referring to with "branch must
> be
> > > > named
> > > > >>>>>> x".
> > > > >>>>>>>> The latest revision of the proposal has only two branches:
> > > master
> > > > >> and
> > > > >>>>>>> next.
> > > > >>>>>>>> Do you mean you don't like the name "next"?
> > > > >>>>>>>>
> > > > >>>>>>>> Maybe the proposal will seem simpler if put in the form of
> > code
> > > :)
> > > > >>>>>>>>
> > > > >>>>>>>> if (!inReleaseMode) {
> > > > >>>>>>>> commitToBranch('master');
> > > > >>>>>>>> } else {
> > > > >>>>>>>> if (isBugFix) {
> > > > >>>>>>>> commitToBranch('next');
> > > > >>>>>>>> mergeBranch('next').into('master');
> > > > >>>>>>>> } else {
> > > > >>>>>>>> commitToBranch('master');
> > > > >>>>>>>> }
> > > > >>>>>>>> }
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>> On Thu, Jan 24, 2013 at 3:06 PM, Braden Shepherdson <
> > > > >>>>>> braden@chromium.org
> > > > >>>>>>>>> wrote:
> > > > >>>>>>>>
> > > > >>>>>>>>> Most of the time the flow will be unchanged: push to
> master.
> > > > >>>>>> Tagging
> > > > >>>>>>>> things
> > > > >>>>>>>>> we already know how to do; that doesn't change.
> > > > >>>>>>>>>
> > > > >>>>>>>>> The only new flow for most people is cherrypicking bug
> fixes
> > > from
> > > > >>>>>>> master
> > > > >>>>>>>> to
> > > > >>>>>>>>> next, which we can give examples of. Plus that could remain
> > the
> > > > >>>>>>>>> responsibility of the main platform maintainers, who are
> > doing
> > > > the
> > > > >>>>>>>> tagging.
> > > > >>>>>>>>>
> > > > >>>>>>>>> Braden
> > > > >>>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>> On Thu, Jan 24, 2013 at 2:56 PM, Jesse <
> > > purplecabbage@gmail.com>
> > > > >>>>>>> wrote:
> > > > >>>>>>>>>
> > > > >>>>>>>>>> On Thu, Jan 24, 2013 at 11:09 AM, Braden Shepherdson <
> > > > >>>>>>>>> braden@chromium.org
> > > > >>>>>>>>>>> wrote:
> > > > >>>>>>>>>>
> > > > >>>>>>>>>>> The founding goal we're trying to accomplish here is that
> > we
> > > > >>>>>> don't
> > > > >>>>>>>> want
> > > > >>>>>>>>>>> everyone sitting on changes to be in the next version
> while
> > > we
> > > > >>>>>> use
> > > > >>>>>>>>> master
> > > > >>>>>>>>>>> to prep a release.
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> I don't think having one branch for prepping the release
> > and
> > > > >>>>>>> another
> > > > >>>>>>>>> for
> > > > >>>>>>>>>>> main development is a lot of bureaucracy.
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> It is not, the 'branch must be named x' is mainly where I
> > have
> > > > >>>>>>>> concerns.
> > > > >>>>>>>>>> Really I just want things simple.
> > > > >>>>>>>>>>
> > > > >>>>>>>>>>
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> On Thu, Jan 24, 2013 at 1:57 PM, Jesse MacFadyen <
> > > > >>>>>>>>>> purplecabbage@gmail.com
> > > > >>>>>>>>>>>> wrote:
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>>> I have been quietly listening on this thread, but
> thought
> > I
> > > > >>>>>>> should
> > > > >>>>>>>> at
> > > > >>>>>>>>>>>> least share my opinion.
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> I don't think adding contribution rules helps anyone.
> Git
> > is
> > > > >>>>>>>>>>>> complicated enough as it is, and this just all seems
> like
> > > > >>>>>>>>> bureaucracy.
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> I think master should always contain the latest stable
> > code,
> > > > >>>>>> and
> > > > >>>>>>> be
> > > > >>>>>>>>>>>> periodically tagged with rc's and versions.
> > > > >>>>>>>>>>>> All work should be done in personal forks and feature
> > > > >>>>>> branches.
> > > > >>>>>>>>>>>> If the latest tag of master is an rc, then we should
> only
> > be
> > > > >>>>>>>> merging
> > > > >>>>>>>>>>>> bugfixes, until the release.
> > > > >>>>>>>>>>>> Immediately after tagging a version we decide which
> > feature
> > > > >>>>>>>> branches
> > > > >>>>>>>>>>>> and pull requests to pull in, and go for it.
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> I don't think this is much different from what we have,
> > but
> > > I
> > > > >>>>>>> think
> > > > >>>>>>>>>>>> that is good.
> > > > >>>>>>>>>>>> The suggestions thus far, while interesting, don't
> > increase
> > > > >>>>>> our
> > > > >>>>>>>>>>>> velocity in my opinion. Also, I can also pretty much
> > > guaranty
> > > > >>>>>>> I'll
> > > > >>>>>>>>>>>> screw it up for the next 3-4 versions. ( because I'm
> dumb
> > )
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> Cheers,
> > > > >>>>>>>>>>>> Jesse
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> On 2013-01-24, at 5:53 AM, Andrew Grieve <
> > > > >>>>>> agrieve@chromium.org>
> > > > >>>>>>>>> wrote:
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> On Wed, Jan 23, 2013 at 4:58 PM, Michael Brooks <
> > > > >>>>>>>>>>> michael@michaelbrooks.ca
> > > > >>>>>>>>>>>>> wrote:
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>>> Before we move forward, I have a few questions about
> the
> > > > >>>>>> "no
> > > > >>>>>>>>> master"
> > > > >>>>>>>>>>>>> approach.
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>> There is *no* master branch, so that community-driven
> > pull
> > > > >>>>>>>> requests
> > > > >>>>>>>>>>> will
> > > > >>>>>>>>>>>> be
> > > > >>>>>>>>>>>>>> forced to think about which branch to request against.
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>> - Andrew, can you cite other projects that do not use a
> > > > >>>>>> master
> > > > >>>>>>>>>> branch?
> > > > >>>>>>>>>>>> This project is my first time using git / github, so I
> > don't
> > > > >>>>>> have
> > > > >>>>>>>>> much
> > > > >>>>>>>>>> to
> > > > >>>>>>>>>>>> draw from. I was going off of others' suggestions on
> this
> > > > >>>>>> thread
> > > > >>>>>>>>> when I
> > > > >>>>>>>>>>>> proposed the names.
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>>> - On Github, you must have a default branch. If not
> > > > >>>>>> master, it
> > > > >>>>>>>> must
> > > > >>>>>>>>>> be
> > > > >>>>>>>>>>>>> something else. So, users are not forced to think about
> > the
> > > > >>>>>>>> branch
> > > > >>>>>>>>> to
> > > > >>>>>>>>>>>> send
> > > > >>>>>>>>>>>>> a pull request again... they will likely just use the
> > > > >>>>>> default.
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> Hmm, good point. The goal is to get people downloading
> > > > >>>>>> Cordova
> > > > >>>>>>> for
> > > > >>>>>>>>> use
> > > > >>>>>>>>>> to
> > > > >>>>>>>>>>>> end up with Stable, and for developers to send pull
> > requests
> > > > >>>>>>>> against
> > > > >>>>>>>>>> dev.
> > > > >>>>>>>>>>>> With a forced default branch, I don't think we can
> > > accomplish
> > > > >>>>>>> this.
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>> - Why is the "stable" branch not just "master"?
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> My thinking was that it's not obvious whether Master ==
> > > > >>>>>> bleeding
> > > > >>>>>>>>> edge,
> > > > >>>>>>>>>> or
> > > > >>>>>>>>>>>> Master == Stable version. Using the names "dev" and
> > "stable"
> > > > >>>>>>> makes
> > > > >>>>>>>>> it a
> > > > >>>>>>>>>>> bit
> > > > >>>>>>>>>>>> clear.
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> So... If github forces us to have a default branch, I'm
> > > > >>>>>> thinking
> > > > >>>>>>>> that
> > > > >>>>>>>>>>>> having users send pull requests against "dev" is more
> > > > >>>>>> valuable
> > > > >>>>>>> than
> > > > >>>>>>>>>>> having
> > > > >>>>>>>>>>>> people download the latest "stable" by default. If
> people
> > > are
> > > > >>>>>>>> pulling
> > > > >>>>>>>>>>> code
> > > > >>>>>>>>>>>> from github rather than from our release .zip files,
> then
> > > > >>>>>> it's
> > > > >>>>>>>> likely
> > > > >>>>>>>>>>> they
> > > > >>>>>>>>>>>> want to hack on it anyways, or that they want the dev
> > > > >>>>>> version to
> > > > >>>>>>>> see
> > > > >>>>>>>>> if
> > > > >>>>>>>>>>>> bugs are fixed.
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> Soo.... Here's version #3! If anyone can think of how to
> > > > >>>>>> keep the
> > > > >>>>>>>>> three
> > > > >>>>>>>>>>>> branches while addressing being forced to have a default
> > > > >>>>>> branch,
> > > > >>>>>>>> feel
> > > > >>>>>>>>>>> free
> > > > >>>>>>>>>>>> to speak up! :)
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> Cordova repositories have two main branches:
> > > > >>>>>>>>>>>> 1. master
> > > > >>>>>>>>>>>> 2. next
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> Topic branches exist for collaborating on features, or
> for
> > > > >>>>>>>>> code-review
> > > > >>>>>>>>>>>> purposes.
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> Cordova uses tags to label releases.
> > > > >>>>>>>>>>>> - Each release candidate has a tag. e.g. "2.2.0rc1"
> > > > >>>>>>>>>>>> - Each release has a tag. e.g. "2.2.0"
> > > > >>>>>>>>>>>> - The "latest" tag points to the last stable release
> (this
> > > > >>>>>>> follows
> > > > >>>>>>>>> npm
> > > > >>>>>>>>>>>> conventions)
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> 1. The "next" branch.
> > > > >>>>>>>>>>>> - This branch is used only when in the process of doing
> a
> > > > >>>>>>> release.
> > > > >>>>>>>>>>>> - All tags are created from this branch.
> > > > >>>>>>>>>>>> - All release-candidate bug-fixes are done on this
> branch.
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> 2. The "master" branch.
> > > > >>>>>>>>>>>> - When not in the release-process, all commits are made
> > here
> > > > >>>>>>>>>>>> - When in the release-process, all non-bugfix commits
> are
> > > > >>>>>> made
> > > > >>>>>>>> here
> > > > >>>>>>>>>>>> - This is where topic-branches are merged into.
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> Cutting a release:
> > > > >>>>>>>>>>>> 1. git checkout next && git merge --ff-only master
> > > > >>>>>>>>>>>> 2. Test test test!
> > > > >>>>>>>>>>>> 3. Fix bugs by committing them directly to "next" and
> then
> > > > >>>>>> doing
> > > > >>>>>>> a
> > > > >>>>>>>>>> non-ff
> > > > >>>>>>>>>>>> merge of next into master
> > > > >>>>>>>>>>>> 4. Tag release candidate
> > > > >>>>>>>>>>>> 5. Repeat steps 2-4 as necessary
> > > > >>>>>>>>>>>> 6. Tag the release (both by version and by updating the
> > > > >>>>>> "latest"
> > > > >>>>>>>> tag)
> > > > >>>>>>>>>>>> 7. Create distribution .zip file
> > > > >>>>>>>>>>>> 8. Test one last time using the dist files
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>> Thanks,
> > > > >>>>>>>>>>>>> Michael
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>> On Wed, Jan 23, 2013 at 11:25 AM, Brian LeRoux <
> > b@brian.io
> > > > >>>>>>>
> > > > >>>>>>>> wrote:
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>> I'm liking it. Start in 2.5?
> > > > >>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>> On Wed, Jan 23, 2013 at 1:19 PM, Filip Maj <
> > fil@adobe.com
> > > > >>>>>>>
> > > > >>>>>>>> wrote:
> > > > >>>>>>>>>>>>>>> Looks great Andrew!
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> If everyone's on board, how are we going to test run
> > > > >>>>>> this?
> > > > >>>>>>>> Flip a
> > > > >>>>>>>>>>>>> switch
> > > > >>>>>>>>>>>>>>> at a certain point, give it a shot with one repo for
> > one
> > > > >>>>>> RC?
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> On 1/22/13 12:29 PM, "Andrew Grieve" <
> > > > >>>>>> agrieve@chromium.org>
> > > > >>>>>>>>> wrote:
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>> Braden, you're right. I've now done some local
> playing
> > > > >>>>>>> around
> > > > >>>>>>>> in
> > > > >>>>>>>>>>> git,
> > > > >>>>>>>>>>>>> and
> > > > >>>>>>>>>>>>>>>> have an updated proposal that uses merges instead of
> > > > >>>>>>> deleting
> > > > >>>>>>>>>>>> branches.
> > > > >>>>>>>>>>>>>>>> PTAL:
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>> Cordova repositories have three main branches:
> > > > >>>>>>>>>>>>>>>> 1. stable
> > > > >>>>>>>>>>>>>>>> 2. next
> > > > >>>>>>>>>>>>>>>> 3. dev
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>> Topic branches also exist for collaborating on
> > > > >>>>>> features, or
> > > > >>>>>>>> for
> > > > >>>>>>>>>>>>>>>> code-review
> > > > >>>>>>>>>>>>>>>> purposes.
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>> There is *no* master branch, so that
> community-driven
> > > > >>>>>> pull
> > > > >>>>>>>>>> requests
> > > > >>>>>>>>>>>>> will
> > > > >>>>>>>>>>>>>>>> be
> > > > >>>>>>>>>>>>>>>> forced to think about which branch to request
> against.
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>> 1. The "stable" branch.
> > > > >>>>>>>>>>>>>>>> - Sits at the latest stable release of cordova
> > > > >>>>>>>>>>>>>>>> - This changes only when doing fast-forward merges
> > from
> > > > >>>>>>> "next"
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>> 2. The "next" branch.
> > > > >>>>>>>>>>>>>>>> - This branch is used only when in the process of
> > doing
> > > > >>>>>> a
> > > > >>>>>>>>> release.
> > > > >>>>>>>>>>>>>>>> - All tags (both stable and RC) are done on this
> > branch.
> > > > >>>>>>>>>>>>>>>> - All release-candidate bug-fixes are done on this
> > > > >>>>>> branch.
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>> 3. The "dev" branch.
> > > > >>>>>>>>>>>>>>>> - This is where non-release-candidate commits are
> done
> > > > >>>>>>>>>>>>>>>> - This is where topic-branches are merged into.
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>> Cutting a release:
> > > > >>>>>>>>>>>>>>>> 1. git checkout next && git merge --ff-only dev
> > > > >>>>>>>>>>>>>>>> 2. Test test test!
> > > > >>>>>>>>>>>>>>>> 3. Fix bugs by committing them directly to "next"
> and
> > > > >>>>>> then
> > > > >>>>>>>>> doing a
> > > > >>>>>>>>>>>>> non-ff
> > > > >>>>>>>>>>>>>>>> merge of next into dev
> > > > >>>>>>>>>>>>>>>> 4. Tag release candidate
> > > > >>>>>>>>>>>>>>>> 5. Repeat steps 2-4 as necessary
> > > > >>>>>>>>>>>>>>>> 6. Tag the release
> > > > >>>>>>>>>>>>>>>> 7. Create distribution .zip file
> > > > >>>>>>>>>>>>>>>> 8. Test one last time using the dist files
> > > > >>>>>>>>>>>>>>>> 9. git checkout stable && git merge --ff-only next
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>> On Tue, Jan 22, 2013 at 1:59 PM, Braden Shepherdson
> > > > >>>>>>>>>>>>>>>> <br...@chromium.org>wrote:
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>> I think deleting and recreating branches with the
> > same
> > > > >>>>>> name
> > > > >>>>>>>> can
> > > > >>>>>>>>>>> cause
> > > > >>>>>>>>>>>>>>>>> badness in git[1] because of remotes. It's not
> really
> > > > >>>>>> the
> > > > >>>>>>>> same
> > > > >>>>>>>>>>> branch
> > > > >>>>>>>>>>>>>> in
> > > > >>>>>>>>>>>>>>>>> terms of commits, and git thinks that your old
> stable
> > > > >>>>>> and
> > > > >>>>>>> the
> > > > >>>>>>>>> new
> > > > >>>>>>>>>>>>>> stable
> > > > >>>>>>>>>>>>>>>>> differ by all of each of their commits. Tags can be
> > > > >>>>>> moved
> > > > >>>>>>>>>>>>> arbitrarily,
> > > > >>>>>>>>>>>>>>>>> so I
> > > > >>>>>>>>>>>>>>>>> think stable makes sense as a tag. I'm not sure
> about
> > > > >>>>>> how
> > > > >>>>>>>> best
> > > > >>>>>>>>> to
> > > > >>>>>>>>>>>>>> handle
> > > > >>>>>>>>>>>>>>>>> next.
> > > > >>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>> [1]
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>
> > > > >>>>>>
> > > > >>
> > > >
> > >
> >
> http://stackoverflow.com/questions/11844581/git-delete-and-recreate-branc
> > > > >>>>>>>>>>>>>>>>> h
> > > > >>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>> On Tue, Jan 22, 2013 at 11:31 AM, Andrew Grieve <
> > > > >>>>>>>>>>>>> agrieve@chromium.org
> > > > >>>>>>>>>>>>>>>>>> wrote:
> > > > >>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>> Michal's attending hackathons for the week, and
> I'm
> > > > >>>>>> not
> > > > >>>>>>> sure
> > > > >>>>>>>>> we
> > > > >>>>>>>>>>>>> need
> > > > >>>>>>>>>>>>>>>>> to
> > > > >>>>>>>>>>>>>>>>> do
> > > > >>>>>>>>>>>>>>>>>> a hang-out for this, as I think we really are
> quite
> > > > >>>>>> close
> > > > >>>>>>> to
> > > > >>>>>>>>>>>>>> resolving
> > > > >>>>>>>>>>>>>>>>>> this. I'd really like to resolve this ASAP so that
> > we
> > > > >>>>>>> don't
> > > > >>>>>>>>> need
> > > > >>>>>>>>>>> to
> > > > >>>>>>>>>>>>>>>>> have
> > > > >>>>>>>>>>>>>>>>> a
> > > > >>>>>>>>>>>>>>>>>> code-freeze for this release.
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>> Here's a proposal:
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>> Cordova repositories have three main branches:
> > > > >>>>>>>>>>>>>>>>>> 1. stable
> > > > >>>>>>>>>>>>>>>>>> 2. next
> > > > >>>>>>>>>>>>>>>>>> 3. dev
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>> Topic branches also exist for collaborating on
> > > > >>>>>> features,
> > > > >>>>>>> or
> > > > >>>>>>>>> for
> > > > >>>>>>>>>>>>>>>>> code-review
> > > > >>>>>>>>>>>>>>>>>> purposes.
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>> There is *no* master branch, so that
> > community-driven
> > > > >>>>>> pull
> > > > >>>>>>>>>>> requests
> > > > >>>>>>>>>>>>>>>>> will
> > > > >>>>>>>>>>>>>>>>> be
> > > > >>>>>>>>>>>>>>>>>> forced to think about which branch to request
> > against.
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>> 1. The "stable" branch.
> > > > >>>>>>>>>>>>>>>>>> - Sits at the latest stable release of cordova
> > > > >>>>>>>>>>>>>>>>>> - No one ever commits to the "stable" branch. It
> > > > >>>>>> exists
> > > > >>>>>>> only
> > > > >>>>>>>>> as
> > > > >>>>>>>>>> a
> > > > >>>>>>>>>>>>>>>>>> short-cut for checking out the latest stable tag.
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>> 2. The "next" branch.
> > > > >>>>>>>>>>>>>>>>>> - This branch exists only when in the process of
> > > > >>>>>> doing a
> > > > >>>>>>>>>> release.
> > > > >>>>>>>>>>>>>>>>>> - All tags (both stable and RC) are done on this
> > > > >>>>>> branch.
> > > > >>>>>>>>>>>>>>>>>> - When a stable tag is done:
> > > > >>>>>>>>>>>>>>>>>> - The existing "stable" branch is deleted
> > > > >>>>>>>>>>>>>>>>>> - A new "stable" branch is created from "next".
> > > > >>>>>>>>>>>>>>>>>> - The "next" branch is deleted.
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>> 3. The "dev" branch.
> > > > >>>>>>>>>>>>>>>>>> - This is where all commits are done
> > > > >>>>>>>>>>>>>>>>>> - This is where topic-branches are merged into.
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>> Cutting a release:
> > > > >>>>>>>>>>>>>>>>>> 1. Create "next" from the HEAD of "dev"
> > > > >>>>>>>>>>>>>>>>>> 2. Test test test!
> > > > >>>>>>>>>>>>>>>>>> 3. Fix bugs by committing them to "dev" and then
> > > > >>>>>>>>> cherry-picking
> > > > >>>>>>>>>>>>> them
> > > > >>>>>>>>>>>>>>>>> into
> > > > >>>>>>>>>>>>>>>>>> "next"
> > > > >>>>>>>>>>>>>>>>>> 4. Tag release candidate
> > > > >>>>>>>>>>>>>>>>>> 5. Repeat steps 2-4 as necessary
> > > > >>>>>>>>>>>>>>>>>> 6. Tag the release
> > > > >>>>>>>>>>>>>>>>>> 7. Create distribution .zip file
> > > > >>>>>>>>>>>>>>>>>> 8. Test one last time using the dist files
> > > > >>>>>>>>>>>>>>>>>> 9. Delete "stable"
> > > > >>>>>>>>>>>>>>>>>> 10. Create a new "stable" by branching from the
> HEAD
> > > > >>>>>> of
> > > > >>>>>>>> "next"
> > > > >>>>>>>>>>>>>>>>>> 11. Delete the "next" branch
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>> On Wed, Jan 16, 2013 at 10:34 AM, Michal Mocny <
> > > > >>>>>>>>>>>>> mmocny@chromium.org>
> > > > >>>>>>>>>>>>>>>>>> wrote:
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>> Just going to throw out one of my personal
> > > > >>>>>> requirements
> > > > >>>>>>> for
> > > > >>>>>>>>>>>>>> whatever
> > > > >>>>>>>>>>>>>>>>>>> proposal we come up with, so it doesn't get lost:
> > > > >>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>> * Feature branches are great for feature work
> > and/or
> > > > >>>>>>> large
> > > > >>>>>>>>>>>>> sweeping
> > > > >>>>>>>>>>>>>>>>>>> changes, as are JIRA bugs for tracking them, but
> > > > >>>>>> cordova
> > > > >>>>>>>> has
> > > > >>>>>>>>>> many
> > > > >>>>>>>>>>>>>>>>> many
> > > > >>>>>>>>>>>>>>>>>>> trivial issues that could be fixed with
> "drive-by"
> > > > >>>>>>> patches
> > > > >>>>>>>>> that
> > > > >>>>>>>>>>>>>>>>> require
> > > > >>>>>>>>>>>>>>>>>> as
> > > > >>>>>>>>>>>>>>>>>>> little friction to commit as possible.
> > > > >>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>> On Tue, Jan 15, 2013 at 3:05 PM, Marcel Kinard <
> > > > >>>>>>>>>>>>> cmarcelk@gmail.com
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>> wrote:
> > > > >>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>> How about if there is a specific straw man
> > proposal
> > > > >>>>>> at
> > > > >>>>>>> the
> > > > >>>>>>>>>>>>>>>>> beginning
> > > > >>>>>>>>>>>>>>>>> of
> > > > >>>>>>>>>>>>>>>>>>>> the face-time? Then the folks that are in
> > agreement
> > > > >>>>>>> won't
> > > > >>>>>>>>> need
> > > > >>>>>>>>>>>>> to
> > > > >>>>>>>>>>>>>>>>> say
> > > > >>>>>>>>>>>>>>>>>>>> anything ;-)
> > > > >>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>> Seriously, making adjustments to something
> > tangible
> > > > >>>>>> is
> > > > >>>>>>>>> easier
> > > > >>>>>>>>>>>>>> than
> > > > >>>>>>>>>>>>>>>>>>>> instantiating it from scratch. A volunteer for a
> > > > >>>>>> very
> > > > >>>>>>>> simple
> > > > >>>>>>>>>>>>>>>>> writeup
> > > > >>>>>>>>>>>>>>>>> on
> > > > >>>>>>>>>>>>>>>>>>> the
> > > > >>>>>>>>>>>>>>>>>>>> wiki?
> > > > >>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>> -- Marcel Kinard
> > > > >>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>> On 1/14/2013 10:06 PM, Michal Mocny wrote:
> > > > >>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>> Okay gentlemen, I think there have been
> countless
> > > > >>>>>> good
> > > > >>>>>>>>> points
> > > > >>>>>>>>>>>>>>>>> made
> > > > >>>>>>>>>>>>>>>>>> from
> > > > >>>>>>>>>>>>>>>>>>>>> all
> > > > >>>>>>>>>>>>>>>>>>>>> parties, but also some bike-shedding.
> > > > >>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>> Perhaps it is time to schedule some face-time
> to
> > > > >>>>>> better
> > > > >>>>>>>>>>>>>>>>> articulate
> > > > >>>>>>>>>>>>>>>>>> some
> > > > >>>>>>>>>>>>>>>>>>> of
> > > > >>>>>>>>>>>>>>>>>>>>> the finer points, and to help come to some
> > > > >>>>>> consensus?
> > > > >>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>> -Michal
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>
> > > > >>>>>>>>>>
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> --
> > > > >>>>>>>>>> @purplecabbage
> > > > >>>>>>>>>> risingj.com
> > > > >>>>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>> --
> > > > >>>>>>> @purplecabbage
> > > > >>>>>>> risingj.com
> > > > >>>>>>>
> > > > >>>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>
> > > > >>>
> > > > >>>
> > > > >>> --
> > > > >>> @purplecabbage
> > > > >>> risingj.com
> > > > >>
> > > > >>
> > > >
> > > >
> > >
> >
>
Re: too long to package a release?
Posted by Becky Gibson <gi...@gmail.com>.
Thank you, Michael! I do usually go a git push --dry-run to check that I
am pushing what I expect but I'll try the diff as well.
On Wed, Feb 20, 2013 at 1:07 PM, Michal Mocny <mm...@chromium.org> wrote:
> So there is also http://wiki.apache.org/cordova/CuttingReleases which may
> be useful (esp Taggin section).
>
> As far as the confusion with the two branch names: "topic_branch" is your
> local working branch for a bugfix/feature, and "to_be_merged" is really
> "temporary_new_name_for_a_branch_to_do_rebase_in". I usually skip that
> step and take the risk or rebasing in topic_branch (aside: this may
> negatively affect diffs if you push updates for a review-edit-re-review
> cycle -- but this isn't an issue for cordova).
>
> Do not checkout 'next' into your master branch. Update your local branches
> to include the remote next branch (with 'git pull apache' with no branch)
> then you can switch to the next branch locally, apply your patch there, and
> push to that remote branch directly. Later, merge that commit into master
> locally, and push that.
>
> Do not push to apache next from your local master, or else you will push
> all the changes.
>
> I agree, this is a little confusing, but after a few practice runs it
> should be easy to figure out. You should probably also check what would be
> pushed with 'git diff apache/[target-branch]' or tag on --stat to that to
> just see that files that would signal a quick "uh-oh".
>
> I'll work to update the wiki later today, and likely others will have more
> tips on how to make sure we don't make mistakes.
>
> -Michal
>
>
>
> On Wed, Feb 20, 2013 at 12:42 PM, Becky Gibson <gibson.becky@gmail.com
> >wrote:
>
> > Can someone please provide a "git cordova release process for dummies"
> > example to make sure I do the release commits and merges properly (the
> > committerWorkflow example didn't help me as I didn't understand the
> > topic_branch and to_be_merged distinction)
> >
> > At any rate, can I do a git checkout apache next into my "master" branch?
> > Then I can checkout my working_branch, rebase master (which contains
> the
> > next code) checkout master, merge my fix and push apache next.
> > git checkout apache next
> > git checkout working_branch_with_fix
> > git rebase master
> > git checkout master
> > git merge working_branch_with_fix
> > git push apache next
> >
> > and then repeat this for apache master with the possibility of needing to
> > use -ff when I merge. Am I on the right track?
> >
> > humbled by git,
> > -becky
> >
> > On Fri, Feb 8, 2013 at 5:22 PM, Marcel Kinard <cm...@gmail.com>
> wrote:
> >
> > > Nice! Thanks, Andrew!
> > >
> > > -- Marcel Kinard
> > >
> > > On Feb 7, 2013, at 2:59 PM, Andrew Grieve <ag...@chromium.org>
> wrote:
> > >
> > > > The doc's not up-to-date, but I think we ended on consensus for the
> > code
> > > > version. I've taken a stab at updating the wiki pages:
> > > >
> > > > http://wiki.apache.org/cordova/CordovaAndGit -- Added the idea of
> > > having
> > > > both a master and a next branch
> > > > http://wiki.apache.org/cordova/CommitterWorkflow -- Added Jesse's
> > > version
> > > > of the "which branch - in code"
> > > > http://wiki.apache.org/cordova/CuttingReleases -- Changed tagging
> > > > instructions to refer to the "next" branch
> > > >
> > > >
> > > > On Thu, Feb 7, 2013 at 1:26 PM, Marcel Kinard <cm...@gmail.com>
> > > wrote:
> > > >
> > > >> With 2.5 starting, it appears time to poke this thread.
> > > >>
> > > >> - Is the Google doc refreshed with the latest consensus?
> > > >> - If so, should the Google doc be transferred to a wiki page?
> > > >> - Have the necessary branches been created?
> > > >> - Are we all in the boat, and understand how to row this beast?
> > > >>
> > > >> -- Marcel Kinard
> > > >>
> > > >> On Jan 24, 2013, at 5:14 PM, Jesse <pu...@gmail.com> wrote:
> > > >>
> > > >>> Nice Shaz, but I was hoping it was a github style network
> > visualization
> > > >>> that included a few versions worth of merges.
> > > >>> Who wants to draw that?
> > > >>>
> > > >>> On Thu, Jan 24, 2013 at 2:05 PM, Shazron <sh...@gmail.com>
> wrote:
> > > >>>
> > > >>>> Inline image got mangled, here it is linked: http://cl.ly/MOrD
> > > >>>>
> > > >>>>
> > > >>>> On Thu, Jan 24, 2013 at 1:39 PM, Shazron <sh...@gmail.com>
> wrote:
> > > >>>>
> > > >>>>> Thanks for the pseudocode Andrew, seems simpler to understand ;)
> > > >> Jesse's
> > > >>>>> re-factor makes it even easier. Here's my contrib for those more
> > > >> visually
> > > >>>>> inclined:
> > > >>>>>
> > > >>>>>
> > > >>>>> [image: Inline image 2]
> > > >>>>>
> > > >>>>>
> > > >>>>> On Thu, Jan 24, 2013 at 1:29 PM, Andrew Grieve <
> > agrieve@chromium.org
> > > >>> wrote:
> > > >>>>>
> > > >>>>>> Nice! even simpler. :)
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> On Thu, Jan 24, 2013 at 3:44 PM, Jesse <purplecabbage@gmail.com
> >
> > > >> wrote:
> > > >>>>>>
> > > >>>>>>> Thanks for clarifying Andrew. et al, I guess I was
> > > mis-understanding
> > > >>>>>> some
> > > >>>>>>> of the earlier discussion around naming stuff.
> > > >>>>>>>
> > > >>>>>>> So everything is going to master all the time, and we only care
> > > about
> > > >>>>>>> 'next' if we are inReleaseMode and it is a bug fix?
> > > >>>>>>>
> > > >>>>>>> if(inReleaseMode && isBugFix) {
> > > >>>>>>> commitToBranch('next');
> > > >>>>>>> mergeBranch('next').into('master');
> > > >>>>>>> }
> > > >>>>>>> else {
> > > >>>>>>> commitToBranch('master');
> > > >>>>>>> }
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>> On Thu, Jan 24, 2013 at 12:29 PM, Andrew Grieve <
> > > >> agrieve@chromium.org
> > > >>>>>>>> wrote:
> > > >>>>>>>
> > > >>>>>>>> Just to clarify - there should be *no* using of the git
> > > >>>>>> cherry-picking
> > > >>>>>>>> command, only git merge.
> > > >>>>>>>>
> > > >>>>>>>> Jesse - not sure what you're referring to with "branch must be
> > > named
> > > >>>>>> x".
> > > >>>>>>>> The latest revision of the proposal has only two branches:
> > master
> > > >> and
> > > >>>>>>> next.
> > > >>>>>>>> Do you mean you don't like the name "next"?
> > > >>>>>>>>
> > > >>>>>>>> Maybe the proposal will seem simpler if put in the form of
> code
> > :)
> > > >>>>>>>>
> > > >>>>>>>> if (!inReleaseMode) {
> > > >>>>>>>> commitToBranch('master');
> > > >>>>>>>> } else {
> > > >>>>>>>> if (isBugFix) {
> > > >>>>>>>> commitToBranch('next');
> > > >>>>>>>> mergeBranch('next').into('master');
> > > >>>>>>>> } else {
> > > >>>>>>>> commitToBranch('master');
> > > >>>>>>>> }
> > > >>>>>>>> }
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> On Thu, Jan 24, 2013 at 3:06 PM, Braden Shepherdson <
> > > >>>>>> braden@chromium.org
> > > >>>>>>>>> wrote:
> > > >>>>>>>>
> > > >>>>>>>>> Most of the time the flow will be unchanged: push to master.
> > > >>>>>> Tagging
> > > >>>>>>>> things
> > > >>>>>>>>> we already know how to do; that doesn't change.
> > > >>>>>>>>>
> > > >>>>>>>>> The only new flow for most people is cherrypicking bug fixes
> > from
> > > >>>>>>> master
> > > >>>>>>>> to
> > > >>>>>>>>> next, which we can give examples of. Plus that could remain
> the
> > > >>>>>>>>> responsibility of the main platform maintainers, who are
> doing
> > > the
> > > >>>>>>>> tagging.
> > > >>>>>>>>>
> > > >>>>>>>>> Braden
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>> On Thu, Jan 24, 2013 at 2:56 PM, Jesse <
> > purplecabbage@gmail.com>
> > > >>>>>>> wrote:
> > > >>>>>>>>>
> > > >>>>>>>>>> On Thu, Jan 24, 2013 at 11:09 AM, Braden Shepherdson <
> > > >>>>>>>>> braden@chromium.org
> > > >>>>>>>>>>> wrote:
> > > >>>>>>>>>>
> > > >>>>>>>>>>> The founding goal we're trying to accomplish here is that
> we
> > > >>>>>> don't
> > > >>>>>>>> want
> > > >>>>>>>>>>> everyone sitting on changes to be in the next version while
> > we
> > > >>>>>> use
> > > >>>>>>>>> master
> > > >>>>>>>>>>> to prep a release.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> I don't think having one branch for prepping the release
> and
> > > >>>>>>> another
> > > >>>>>>>>> for
> > > >>>>>>>>>>> main development is a lot of bureaucracy.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>> It is not, the 'branch must be named x' is mainly where I
> have
> > > >>>>>>>> concerns.
> > > >>>>>>>>>> Really I just want things simple.
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> On Thu, Jan 24, 2013 at 1:57 PM, Jesse MacFadyen <
> > > >>>>>>>>>> purplecabbage@gmail.com
> > > >>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>> I have been quietly listening on this thread, but thought
> I
> > > >>>>>>> should
> > > >>>>>>>> at
> > > >>>>>>>>>>>> least share my opinion.
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> I don't think adding contribution rules helps anyone. Git
> is
> > > >>>>>>>>>>>> complicated enough as it is, and this just all seems like
> > > >>>>>>>>> bureaucracy.
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> I think master should always contain the latest stable
> code,
> > > >>>>>> and
> > > >>>>>>> be
> > > >>>>>>>>>>>> periodically tagged with rc's and versions.
> > > >>>>>>>>>>>> All work should be done in personal forks and feature
> > > >>>>>> branches.
> > > >>>>>>>>>>>> If the latest tag of master is an rc, then we should only
> be
> > > >>>>>>>> merging
> > > >>>>>>>>>>>> bugfixes, until the release.
> > > >>>>>>>>>>>> Immediately after tagging a version we decide which
> feature
> > > >>>>>>>> branches
> > > >>>>>>>>>>>> and pull requests to pull in, and go for it.
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> I don't think this is much different from what we have,
> but
> > I
> > > >>>>>>> think
> > > >>>>>>>>>>>> that is good.
> > > >>>>>>>>>>>> The suggestions thus far, while interesting, don't
> increase
> > > >>>>>> our
> > > >>>>>>>>>>>> velocity in my opinion. Also, I can also pretty much
> > guaranty
> > > >>>>>>> I'll
> > > >>>>>>>>>>>> screw it up for the next 3-4 versions. ( because I'm dumb
> )
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> Cheers,
> > > >>>>>>>>>>>> Jesse
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> On 2013-01-24, at 5:53 AM, Andrew Grieve <
> > > >>>>>> agrieve@chromium.org>
> > > >>>>>>>>> wrote:
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> On Wed, Jan 23, 2013 at 4:58 PM, Michael Brooks <
> > > >>>>>>>>>>> michael@michaelbrooks.ca
> > > >>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>> Before we move forward, I have a few questions about the
> > > >>>>>> "no
> > > >>>>>>>>> master"
> > > >>>>>>>>>>>>> approach.
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> There is *no* master branch, so that community-driven
> pull
> > > >>>>>>>> requests
> > > >>>>>>>>>>> will
> > > >>>>>>>>>>>> be
> > > >>>>>>>>>>>>>> forced to think about which branch to request against.
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> - Andrew, can you cite other projects that do not use a
> > > >>>>>> master
> > > >>>>>>>>>> branch?
> > > >>>>>>>>>>>> This project is my first time using git / github, so I
> don't
> > > >>>>>> have
> > > >>>>>>>>> much
> > > >>>>>>>>>> to
> > > >>>>>>>>>>>> draw from. I was going off of others' suggestions on this
> > > >>>>>> thread
> > > >>>>>>>>> when I
> > > >>>>>>>>>>>> proposed the names.
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>> - On Github, you must have a default branch. If not
> > > >>>>>> master, it
> > > >>>>>>>> must
> > > >>>>>>>>>> be
> > > >>>>>>>>>>>>> something else. So, users are not forced to think about
> the
> > > >>>>>>>> branch
> > > >>>>>>>>> to
> > > >>>>>>>>>>>> send
> > > >>>>>>>>>>>>> a pull request again... they will likely just use the
> > > >>>>>> default.
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> Hmm, good point. The goal is to get people downloading
> > > >>>>>> Cordova
> > > >>>>>>> for
> > > >>>>>>>>> use
> > > >>>>>>>>>> to
> > > >>>>>>>>>>>> end up with Stable, and for developers to send pull
> requests
> > > >>>>>>>> against
> > > >>>>>>>>>> dev.
> > > >>>>>>>>>>>> With a forced default branch, I don't think we can
> > accomplish
> > > >>>>>>> this.
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> - Why is the "stable" branch not just "master"?
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> My thinking was that it's not obvious whether Master ==
> > > >>>>>> bleeding
> > > >>>>>>>>> edge,
> > > >>>>>>>>>> or
> > > >>>>>>>>>>>> Master == Stable version. Using the names "dev" and
> "stable"
> > > >>>>>>> makes
> > > >>>>>>>>> it a
> > > >>>>>>>>>>> bit
> > > >>>>>>>>>>>> clear.
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> So... If github forces us to have a default branch, I'm
> > > >>>>>> thinking
> > > >>>>>>>> that
> > > >>>>>>>>>>>> having users send pull requests against "dev" is more
> > > >>>>>> valuable
> > > >>>>>>> than
> > > >>>>>>>>>>> having
> > > >>>>>>>>>>>> people download the latest "stable" by default. If people
> > are
> > > >>>>>>>> pulling
> > > >>>>>>>>>>> code
> > > >>>>>>>>>>>> from github rather than from our release .zip files, then
> > > >>>>>> it's
> > > >>>>>>>> likely
> > > >>>>>>>>>>> they
> > > >>>>>>>>>>>> want to hack on it anyways, or that they want the dev
> > > >>>>>> version to
> > > >>>>>>>> see
> > > >>>>>>>>> if
> > > >>>>>>>>>>>> bugs are fixed.
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> Soo.... Here's version #3! If anyone can think of how to
> > > >>>>>> keep the
> > > >>>>>>>>> three
> > > >>>>>>>>>>>> branches while addressing being forced to have a default
> > > >>>>>> branch,
> > > >>>>>>>> feel
> > > >>>>>>>>>>> free
> > > >>>>>>>>>>>> to speak up! :)
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> Cordova repositories have two main branches:
> > > >>>>>>>>>>>> 1. master
> > > >>>>>>>>>>>> 2. next
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> Topic branches exist for collaborating on features, or for
> > > >>>>>>>>> code-review
> > > >>>>>>>>>>>> purposes.
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> Cordova uses tags to label releases.
> > > >>>>>>>>>>>> - Each release candidate has a tag. e.g. "2.2.0rc1"
> > > >>>>>>>>>>>> - Each release has a tag. e.g. "2.2.0"
> > > >>>>>>>>>>>> - The "latest" tag points to the last stable release (this
> > > >>>>>>> follows
> > > >>>>>>>>> npm
> > > >>>>>>>>>>>> conventions)
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> 1. The "next" branch.
> > > >>>>>>>>>>>> - This branch is used only when in the process of doing a
> > > >>>>>>> release.
> > > >>>>>>>>>>>> - All tags are created from this branch.
> > > >>>>>>>>>>>> - All release-candidate bug-fixes are done on this branch.
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> 2. The "master" branch.
> > > >>>>>>>>>>>> - When not in the release-process, all commits are made
> here
> > > >>>>>>>>>>>> - When in the release-process, all non-bugfix commits are
> > > >>>>>> made
> > > >>>>>>>> here
> > > >>>>>>>>>>>> - This is where topic-branches are merged into.
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> Cutting a release:
> > > >>>>>>>>>>>> 1. git checkout next && git merge --ff-only master
> > > >>>>>>>>>>>> 2. Test test test!
> > > >>>>>>>>>>>> 3. Fix bugs by committing them directly to "next" and then
> > > >>>>>> doing
> > > >>>>>>> a
> > > >>>>>>>>>> non-ff
> > > >>>>>>>>>>>> merge of next into master
> > > >>>>>>>>>>>> 4. Tag release candidate
> > > >>>>>>>>>>>> 5. Repeat steps 2-4 as necessary
> > > >>>>>>>>>>>> 6. Tag the release (both by version and by updating the
> > > >>>>>> "latest"
> > > >>>>>>>> tag)
> > > >>>>>>>>>>>> 7. Create distribution .zip file
> > > >>>>>>>>>>>> 8. Test one last time using the dist files
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> Thanks,
> > > >>>>>>>>>>>>> Michael
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> On Wed, Jan 23, 2013 at 11:25 AM, Brian LeRoux <
> b@brian.io
> > > >>>>>>>
> > > >>>>>>>> wrote:
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> I'm liking it. Start in 2.5?
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> On Wed, Jan 23, 2013 at 1:19 PM, Filip Maj <
> fil@adobe.com
> > > >>>>>>>
> > > >>>>>>>> wrote:
> > > >>>>>>>>>>>>>>> Looks great Andrew!
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> If everyone's on board, how are we going to test run
> > > >>>>>> this?
> > > >>>>>>>> Flip a
> > > >>>>>>>>>>>>> switch
> > > >>>>>>>>>>>>>>> at a certain point, give it a shot with one repo for
> one
> > > >>>>>> RC?
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> On 1/22/13 12:29 PM, "Andrew Grieve" <
> > > >>>>>> agrieve@chromium.org>
> > > >>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> Braden, you're right. I've now done some local playing
> > > >>>>>>> around
> > > >>>>>>>> in
> > > >>>>>>>>>>> git,
> > > >>>>>>>>>>>>> and
> > > >>>>>>>>>>>>>>>> have an updated proposal that uses merges instead of
> > > >>>>>>> deleting
> > > >>>>>>>>>>>> branches.
> > > >>>>>>>>>>>>>>>> PTAL:
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> Cordova repositories have three main branches:
> > > >>>>>>>>>>>>>>>> 1. stable
> > > >>>>>>>>>>>>>>>> 2. next
> > > >>>>>>>>>>>>>>>> 3. dev
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> Topic branches also exist for collaborating on
> > > >>>>>> features, or
> > > >>>>>>>> for
> > > >>>>>>>>>>>>>>>> code-review
> > > >>>>>>>>>>>>>>>> purposes.
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> There is *no* master branch, so that community-driven
> > > >>>>>> pull
> > > >>>>>>>>>> requests
> > > >>>>>>>>>>>>> will
> > > >>>>>>>>>>>>>>>> be
> > > >>>>>>>>>>>>>>>> forced to think about which branch to request against.
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> 1. The "stable" branch.
> > > >>>>>>>>>>>>>>>> - Sits at the latest stable release of cordova
> > > >>>>>>>>>>>>>>>> - This changes only when doing fast-forward merges
> from
> > > >>>>>>> "next"
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> 2. The "next" branch.
> > > >>>>>>>>>>>>>>>> - This branch is used only when in the process of
> doing
> > > >>>>>> a
> > > >>>>>>>>> release.
> > > >>>>>>>>>>>>>>>> - All tags (both stable and RC) are done on this
> branch.
> > > >>>>>>>>>>>>>>>> - All release-candidate bug-fixes are done on this
> > > >>>>>> branch.
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> 3. The "dev" branch.
> > > >>>>>>>>>>>>>>>> - This is where non-release-candidate commits are done
> > > >>>>>>>>>>>>>>>> - This is where topic-branches are merged into.
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> Cutting a release:
> > > >>>>>>>>>>>>>>>> 1. git checkout next && git merge --ff-only dev
> > > >>>>>>>>>>>>>>>> 2. Test test test!
> > > >>>>>>>>>>>>>>>> 3. Fix bugs by committing them directly to "next" and
> > > >>>>>> then
> > > >>>>>>>>> doing a
> > > >>>>>>>>>>>>> non-ff
> > > >>>>>>>>>>>>>>>> merge of next into dev
> > > >>>>>>>>>>>>>>>> 4. Tag release candidate
> > > >>>>>>>>>>>>>>>> 5. Repeat steps 2-4 as necessary
> > > >>>>>>>>>>>>>>>> 6. Tag the release
> > > >>>>>>>>>>>>>>>> 7. Create distribution .zip file
> > > >>>>>>>>>>>>>>>> 8. Test one last time using the dist files
> > > >>>>>>>>>>>>>>>> 9. git checkout stable && git merge --ff-only next
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> On Tue, Jan 22, 2013 at 1:59 PM, Braden Shepherdson
> > > >>>>>>>>>>>>>>>> <br...@chromium.org>wrote:
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> I think deleting and recreating branches with the
> same
> > > >>>>>> name
> > > >>>>>>>> can
> > > >>>>>>>>>>> cause
> > > >>>>>>>>>>>>>>>>> badness in git[1] because of remotes. It's not really
> > > >>>>>> the
> > > >>>>>>>> same
> > > >>>>>>>>>>> branch
> > > >>>>>>>>>>>>>> in
> > > >>>>>>>>>>>>>>>>> terms of commits, and git thinks that your old stable
> > > >>>>>> and
> > > >>>>>>> the
> > > >>>>>>>>> new
> > > >>>>>>>>>>>>>> stable
> > > >>>>>>>>>>>>>>>>> differ by all of each of their commits. Tags can be
> > > >>>>>> moved
> > > >>>>>>>>>>>>> arbitrarily,
> > > >>>>>>>>>>>>>>>>> so I
> > > >>>>>>>>>>>>>>>>> think stable makes sense as a tag. I'm not sure about
> > > >>>>>> how
> > > >>>>>>>> best
> > > >>>>>>>>> to
> > > >>>>>>>>>>>>>> handle
> > > >>>>>>>>>>>>>>>>> next.
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> [1]
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>
> > > >>>>>>
> > > >>
> > >
> >
> http://stackoverflow.com/questions/11844581/git-delete-and-recreate-branc
> > > >>>>>>>>>>>>>>>>> h
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> On Tue, Jan 22, 2013 at 11:31 AM, Andrew Grieve <
> > > >>>>>>>>>>>>> agrieve@chromium.org
> > > >>>>>>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> Michal's attending hackathons for the week, and I'm
> > > >>>>>> not
> > > >>>>>>> sure
> > > >>>>>>>>> we
> > > >>>>>>>>>>>>> need
> > > >>>>>>>>>>>>>>>>> to
> > > >>>>>>>>>>>>>>>>> do
> > > >>>>>>>>>>>>>>>>>> a hang-out for this, as I think we really are quite
> > > >>>>>> close
> > > >>>>>>> to
> > > >>>>>>>>>>>>>> resolving
> > > >>>>>>>>>>>>>>>>>> this. I'd really like to resolve this ASAP so that
> we
> > > >>>>>>> don't
> > > >>>>>>>>> need
> > > >>>>>>>>>>> to
> > > >>>>>>>>>>>>>>>>> have
> > > >>>>>>>>>>>>>>>>> a
> > > >>>>>>>>>>>>>>>>>> code-freeze for this release.
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> Here's a proposal:
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> Cordova repositories have three main branches:
> > > >>>>>>>>>>>>>>>>>> 1. stable
> > > >>>>>>>>>>>>>>>>>> 2. next
> > > >>>>>>>>>>>>>>>>>> 3. dev
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> Topic branches also exist for collaborating on
> > > >>>>>> features,
> > > >>>>>>> or
> > > >>>>>>>>> for
> > > >>>>>>>>>>>>>>>>> code-review
> > > >>>>>>>>>>>>>>>>>> purposes.
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> There is *no* master branch, so that
> community-driven
> > > >>>>>> pull
> > > >>>>>>>>>>> requests
> > > >>>>>>>>>>>>>>>>> will
> > > >>>>>>>>>>>>>>>>> be
> > > >>>>>>>>>>>>>>>>>> forced to think about which branch to request
> against.
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> 1. The "stable" branch.
> > > >>>>>>>>>>>>>>>>>> - Sits at the latest stable release of cordova
> > > >>>>>>>>>>>>>>>>>> - No one ever commits to the "stable" branch. It
> > > >>>>>> exists
> > > >>>>>>> only
> > > >>>>>>>>> as
> > > >>>>>>>>>> a
> > > >>>>>>>>>>>>>>>>>> short-cut for checking out the latest stable tag.
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> 2. The "next" branch.
> > > >>>>>>>>>>>>>>>>>> - This branch exists only when in the process of
> > > >>>>>> doing a
> > > >>>>>>>>>> release.
> > > >>>>>>>>>>>>>>>>>> - All tags (both stable and RC) are done on this
> > > >>>>>> branch.
> > > >>>>>>>>>>>>>>>>>> - When a stable tag is done:
> > > >>>>>>>>>>>>>>>>>> - The existing "stable" branch is deleted
> > > >>>>>>>>>>>>>>>>>> - A new "stable" branch is created from "next".
> > > >>>>>>>>>>>>>>>>>> - The "next" branch is deleted.
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> 3. The "dev" branch.
> > > >>>>>>>>>>>>>>>>>> - This is where all commits are done
> > > >>>>>>>>>>>>>>>>>> - This is where topic-branches are merged into.
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> Cutting a release:
> > > >>>>>>>>>>>>>>>>>> 1. Create "next" from the HEAD of "dev"
> > > >>>>>>>>>>>>>>>>>> 2. Test test test!
> > > >>>>>>>>>>>>>>>>>> 3. Fix bugs by committing them to "dev" and then
> > > >>>>>>>>> cherry-picking
> > > >>>>>>>>>>>>> them
> > > >>>>>>>>>>>>>>>>> into
> > > >>>>>>>>>>>>>>>>>> "next"
> > > >>>>>>>>>>>>>>>>>> 4. Tag release candidate
> > > >>>>>>>>>>>>>>>>>> 5. Repeat steps 2-4 as necessary
> > > >>>>>>>>>>>>>>>>>> 6. Tag the release
> > > >>>>>>>>>>>>>>>>>> 7. Create distribution .zip file
> > > >>>>>>>>>>>>>>>>>> 8. Test one last time using the dist files
> > > >>>>>>>>>>>>>>>>>> 9. Delete "stable"
> > > >>>>>>>>>>>>>>>>>> 10. Create a new "stable" by branching from the HEAD
> > > >>>>>> of
> > > >>>>>>>> "next"
> > > >>>>>>>>>>>>>>>>>> 11. Delete the "next" branch
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> On Wed, Jan 16, 2013 at 10:34 AM, Michal Mocny <
> > > >>>>>>>>>>>>> mmocny@chromium.org>
> > > >>>>>>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>> Just going to throw out one of my personal
> > > >>>>>> requirements
> > > >>>>>>> for
> > > >>>>>>>>>>>>>> whatever
> > > >>>>>>>>>>>>>>>>>>> proposal we come up with, so it doesn't get lost:
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>> * Feature branches are great for feature work
> and/or
> > > >>>>>>> large
> > > >>>>>>>>>>>>> sweeping
> > > >>>>>>>>>>>>>>>>>>> changes, as are JIRA bugs for tracking them, but
> > > >>>>>> cordova
> > > >>>>>>>> has
> > > >>>>>>>>>> many
> > > >>>>>>>>>>>>>>>>> many
> > > >>>>>>>>>>>>>>>>>>> trivial issues that could be fixed with "drive-by"
> > > >>>>>>> patches
> > > >>>>>>>>> that
> > > >>>>>>>>>>>>>>>>> require
> > > >>>>>>>>>>>>>>>>>> as
> > > >>>>>>>>>>>>>>>>>>> little friction to commit as possible.
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>> On Tue, Jan 15, 2013 at 3:05 PM, Marcel Kinard <
> > > >>>>>>>>>>>>> cmarcelk@gmail.com
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>> How about if there is a specific straw man
> proposal
> > > >>>>>> at
> > > >>>>>>> the
> > > >>>>>>>>>>>>>>>>> beginning
> > > >>>>>>>>>>>>>>>>> of
> > > >>>>>>>>>>>>>>>>>>>> the face-time? Then the folks that are in
> agreement
> > > >>>>>>> won't
> > > >>>>>>>>> need
> > > >>>>>>>>>>>>> to
> > > >>>>>>>>>>>>>>>>> say
> > > >>>>>>>>>>>>>>>>>>>> anything ;-)
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>> Seriously, making adjustments to something
> tangible
> > > >>>>>> is
> > > >>>>>>>>> easier
> > > >>>>>>>>>>>>>> than
> > > >>>>>>>>>>>>>>>>>>>> instantiating it from scratch. A volunteer for a
> > > >>>>>> very
> > > >>>>>>>> simple
> > > >>>>>>>>>>>>>>>>> writeup
> > > >>>>>>>>>>>>>>>>> on
> > > >>>>>>>>>>>>>>>>>>> the
> > > >>>>>>>>>>>>>>>>>>>> wiki?
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>> -- Marcel Kinard
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>> On 1/14/2013 10:06 PM, Michal Mocny wrote:
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>> Okay gentlemen, I think there have been countless
> > > >>>>>> good
> > > >>>>>>>>> points
> > > >>>>>>>>>>>>>>>>> made
> > > >>>>>>>>>>>>>>>>>> from
> > > >>>>>>>>>>>>>>>>>>>>> all
> > > >>>>>>>>>>>>>>>>>>>>> parties, but also some bike-shedding.
> > > >>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>> Perhaps it is time to schedule some face-time to
> > > >>>>>> better
> > > >>>>>>>>>>>>>>>>> articulate
> > > >>>>>>>>>>>>>>>>>> some
> > > >>>>>>>>>>>>>>>>>>> of
> > > >>>>>>>>>>>>>>>>>>>>> the finer points, and to help come to some
> > > >>>>>> consensus?
> > > >>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>> -Michal
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>> --
> > > >>>>>>>>>> @purplecabbage
> > > >>>>>>>>>> risingj.com
> > > >>>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>> --
> > > >>>>>>> @purplecabbage
> > > >>>>>>> risingj.com
> > > >>>>>>>
> > > >>>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>
> > > >>>
> > > >>>
> > > >>> --
> > > >>> @purplecabbage
> > > >>> risingj.com
> > > >>
> > > >>
> > >
> > >
> >
>
Re: too long to package a release?
Posted by Michal Mocny <mm...@chromium.org>.
So there is also http://wiki.apache.org/cordova/CuttingReleases which may
be useful (esp Taggin section).
As far as the confusion with the two branch names: "topic_branch" is your
local working branch for a bugfix/feature, and "to_be_merged" is really
"temporary_new_name_for_a_branch_to_do_rebase_in". I usually skip that
step and take the risk or rebasing in topic_branch (aside: this may
negatively affect diffs if you push updates for a review-edit-re-review
cycle -- but this isn't an issue for cordova).
Do not checkout 'next' into your master branch. Update your local branches
to include the remote next branch (with 'git pull apache' with no branch)
then you can switch to the next branch locally, apply your patch there, and
push to that remote branch directly. Later, merge that commit into master
locally, and push that.
Do not push to apache next from your local master, or else you will push
all the changes.
I agree, this is a little confusing, but after a few practice runs it
should be easy to figure out. You should probably also check what would be
pushed with 'git diff apache/[target-branch]' or tag on --stat to that to
just see that files that would signal a quick "uh-oh".
I'll work to update the wiki later today, and likely others will have more
tips on how to make sure we don't make mistakes.
-Michal
On Wed, Feb 20, 2013 at 12:42 PM, Becky Gibson <gi...@gmail.com>wrote:
> Can someone please provide a "git cordova release process for dummies"
> example to make sure I do the release commits and merges properly (the
> committerWorkflow example didn't help me as I didn't understand the
> topic_branch and to_be_merged distinction)
>
> At any rate, can I do a git checkout apache next into my "master" branch?
> Then I can checkout my working_branch, rebase master (which contains the
> next code) checkout master, merge my fix and push apache next.
> git checkout apache next
> git checkout working_branch_with_fix
> git rebase master
> git checkout master
> git merge working_branch_with_fix
> git push apache next
>
> and then repeat this for apache master with the possibility of needing to
> use -ff when I merge. Am I on the right track?
>
> humbled by git,
> -becky
>
> On Fri, Feb 8, 2013 at 5:22 PM, Marcel Kinard <cm...@gmail.com> wrote:
>
> > Nice! Thanks, Andrew!
> >
> > -- Marcel Kinard
> >
> > On Feb 7, 2013, at 2:59 PM, Andrew Grieve <ag...@chromium.org> wrote:
> >
> > > The doc's not up-to-date, but I think we ended on consensus for the
> code
> > > version. I've taken a stab at updating the wiki pages:
> > >
> > > http://wiki.apache.org/cordova/CordovaAndGit -- Added the idea of
> > having
> > > both a master and a next branch
> > > http://wiki.apache.org/cordova/CommitterWorkflow -- Added Jesse's
> > version
> > > of the "which branch - in code"
> > > http://wiki.apache.org/cordova/CuttingReleases -- Changed tagging
> > > instructions to refer to the "next" branch
> > >
> > >
> > > On Thu, Feb 7, 2013 at 1:26 PM, Marcel Kinard <cm...@gmail.com>
> > wrote:
> > >
> > >> With 2.5 starting, it appears time to poke this thread.
> > >>
> > >> - Is the Google doc refreshed with the latest consensus?
> > >> - If so, should the Google doc be transferred to a wiki page?
> > >> - Have the necessary branches been created?
> > >> - Are we all in the boat, and understand how to row this beast?
> > >>
> > >> -- Marcel Kinard
> > >>
> > >> On Jan 24, 2013, at 5:14 PM, Jesse <pu...@gmail.com> wrote:
> > >>
> > >>> Nice Shaz, but I was hoping it was a github style network
> visualization
> > >>> that included a few versions worth of merges.
> > >>> Who wants to draw that?
> > >>>
> > >>> On Thu, Jan 24, 2013 at 2:05 PM, Shazron <sh...@gmail.com> wrote:
> > >>>
> > >>>> Inline image got mangled, here it is linked: http://cl.ly/MOrD
> > >>>>
> > >>>>
> > >>>> On Thu, Jan 24, 2013 at 1:39 PM, Shazron <sh...@gmail.com> wrote:
> > >>>>
> > >>>>> Thanks for the pseudocode Andrew, seems simpler to understand ;)
> > >> Jesse's
> > >>>>> re-factor makes it even easier. Here's my contrib for those more
> > >> visually
> > >>>>> inclined:
> > >>>>>
> > >>>>>
> > >>>>> [image: Inline image 2]
> > >>>>>
> > >>>>>
> > >>>>> On Thu, Jan 24, 2013 at 1:29 PM, Andrew Grieve <
> agrieve@chromium.org
> > >>> wrote:
> > >>>>>
> > >>>>>> Nice! even simpler. :)
> > >>>>>>
> > >>>>>>
> > >>>>>> On Thu, Jan 24, 2013 at 3:44 PM, Jesse <pu...@gmail.com>
> > >> wrote:
> > >>>>>>
> > >>>>>>> Thanks for clarifying Andrew. et al, I guess I was
> > mis-understanding
> > >>>>>> some
> > >>>>>>> of the earlier discussion around naming stuff.
> > >>>>>>>
> > >>>>>>> So everything is going to master all the time, and we only care
> > about
> > >>>>>>> 'next' if we are inReleaseMode and it is a bug fix?
> > >>>>>>>
> > >>>>>>> if(inReleaseMode && isBugFix) {
> > >>>>>>> commitToBranch('next');
> > >>>>>>> mergeBranch('next').into('master');
> > >>>>>>> }
> > >>>>>>> else {
> > >>>>>>> commitToBranch('master');
> > >>>>>>> }
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> On Thu, Jan 24, 2013 at 12:29 PM, Andrew Grieve <
> > >> agrieve@chromium.org
> > >>>>>>>> wrote:
> > >>>>>>>
> > >>>>>>>> Just to clarify - there should be *no* using of the git
> > >>>>>> cherry-picking
> > >>>>>>>> command, only git merge.
> > >>>>>>>>
> > >>>>>>>> Jesse - not sure what you're referring to with "branch must be
> > named
> > >>>>>> x".
> > >>>>>>>> The latest revision of the proposal has only two branches:
> master
> > >> and
> > >>>>>>> next.
> > >>>>>>>> Do you mean you don't like the name "next"?
> > >>>>>>>>
> > >>>>>>>> Maybe the proposal will seem simpler if put in the form of code
> :)
> > >>>>>>>>
> > >>>>>>>> if (!inReleaseMode) {
> > >>>>>>>> commitToBranch('master');
> > >>>>>>>> } else {
> > >>>>>>>> if (isBugFix) {
> > >>>>>>>> commitToBranch('next');
> > >>>>>>>> mergeBranch('next').into('master');
> > >>>>>>>> } else {
> > >>>>>>>> commitToBranch('master');
> > >>>>>>>> }
> > >>>>>>>> }
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> On Thu, Jan 24, 2013 at 3:06 PM, Braden Shepherdson <
> > >>>>>> braden@chromium.org
> > >>>>>>>>> wrote:
> > >>>>>>>>
> > >>>>>>>>> Most of the time the flow will be unchanged: push to master.
> > >>>>>> Tagging
> > >>>>>>>> things
> > >>>>>>>>> we already know how to do; that doesn't change.
> > >>>>>>>>>
> > >>>>>>>>> The only new flow for most people is cherrypicking bug fixes
> from
> > >>>>>>> master
> > >>>>>>>> to
> > >>>>>>>>> next, which we can give examples of. Plus that could remain the
> > >>>>>>>>> responsibility of the main platform maintainers, who are doing
> > the
> > >>>>>>>> tagging.
> > >>>>>>>>>
> > >>>>>>>>> Braden
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> On Thu, Jan 24, 2013 at 2:56 PM, Jesse <
> purplecabbage@gmail.com>
> > >>>>>>> wrote:
> > >>>>>>>>>
> > >>>>>>>>>> On Thu, Jan 24, 2013 at 11:09 AM, Braden Shepherdson <
> > >>>>>>>>> braden@chromium.org
> > >>>>>>>>>>> wrote:
> > >>>>>>>>>>
> > >>>>>>>>>>> The founding goal we're trying to accomplish here is that we
> > >>>>>> don't
> > >>>>>>>> want
> > >>>>>>>>>>> everyone sitting on changes to be in the next version while
> we
> > >>>>>> use
> > >>>>>>>>> master
> > >>>>>>>>>>> to prep a release.
> > >>>>>>>>>>>
> > >>>>>>>>>>> I don't think having one branch for prepping the release and
> > >>>>>>> another
> > >>>>>>>>> for
> > >>>>>>>>>>> main development is a lot of bureaucracy.
> > >>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> It is not, the 'branch must be named x' is mainly where I have
> > >>>>>>>> concerns.
> > >>>>>>>>>> Really I just want things simple.
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>> On Thu, Jan 24, 2013 at 1:57 PM, Jesse MacFadyen <
> > >>>>>>>>>> purplecabbage@gmail.com
> > >>>>>>>>>>>> wrote:
> > >>>>>>>>>>>
> > >>>>>>>>>>>> I have been quietly listening on this thread, but thought I
> > >>>>>>> should
> > >>>>>>>> at
> > >>>>>>>>>>>> least share my opinion.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> I don't think adding contribution rules helps anyone. Git is
> > >>>>>>>>>>>> complicated enough as it is, and this just all seems like
> > >>>>>>>>> bureaucracy.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> I think master should always contain the latest stable code,
> > >>>>>> and
> > >>>>>>> be
> > >>>>>>>>>>>> periodically tagged with rc's and versions.
> > >>>>>>>>>>>> All work should be done in personal forks and feature
> > >>>>>> branches.
> > >>>>>>>>>>>> If the latest tag of master is an rc, then we should only be
> > >>>>>>>> merging
> > >>>>>>>>>>>> bugfixes, until the release.
> > >>>>>>>>>>>> Immediately after tagging a version we decide which feature
> > >>>>>>>> branches
> > >>>>>>>>>>>> and pull requests to pull in, and go for it.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> I don't think this is much different from what we have, but
> I
> > >>>>>>> think
> > >>>>>>>>>>>> that is good.
> > >>>>>>>>>>>> The suggestions thus far, while interesting, don't increase
> > >>>>>> our
> > >>>>>>>>>>>> velocity in my opinion. Also, I can also pretty much
> guaranty
> > >>>>>>> I'll
> > >>>>>>>>>>>> screw it up for the next 3-4 versions. ( because I'm dumb )
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Cheers,
> > >>>>>>>>>>>> Jesse
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> On 2013-01-24, at 5:53 AM, Andrew Grieve <
> > >>>>>> agrieve@chromium.org>
> > >>>>>>>>> wrote:
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> On Wed, Jan 23, 2013 at 4:58 PM, Michael Brooks <
> > >>>>>>>>>>> michael@michaelbrooks.ca
> > >>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>> Before we move forward, I have a few questions about the
> > >>>>>> "no
> > >>>>>>>>> master"
> > >>>>>>>>>>>>> approach.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> There is *no* master branch, so that community-driven pull
> > >>>>>>>> requests
> > >>>>>>>>>>> will
> > >>>>>>>>>>>> be
> > >>>>>>>>>>>>>> forced to think about which branch to request against.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> - Andrew, can you cite other projects that do not use a
> > >>>>>> master
> > >>>>>>>>>> branch?
> > >>>>>>>>>>>> This project is my first time using git / github, so I don't
> > >>>>>> have
> > >>>>>>>>> much
> > >>>>>>>>>> to
> > >>>>>>>>>>>> draw from. I was going off of others' suggestions on this
> > >>>>>> thread
> > >>>>>>>>> when I
> > >>>>>>>>>>>> proposed the names.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>> - On Github, you must have a default branch. If not
> > >>>>>> master, it
> > >>>>>>>> must
> > >>>>>>>>>> be
> > >>>>>>>>>>>>> something else. So, users are not forced to think about the
> > >>>>>>>> branch
> > >>>>>>>>> to
> > >>>>>>>>>>>> send
> > >>>>>>>>>>>>> a pull request again... they will likely just use the
> > >>>>>> default.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Hmm, good point. The goal is to get people downloading
> > >>>>>> Cordova
> > >>>>>>> for
> > >>>>>>>>> use
> > >>>>>>>>>> to
> > >>>>>>>>>>>> end up with Stable, and for developers to send pull requests
> > >>>>>>>> against
> > >>>>>>>>>> dev.
> > >>>>>>>>>>>> With a forced default branch, I don't think we can
> accomplish
> > >>>>>>> this.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> - Why is the "stable" branch not just "master"?
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> My thinking was that it's not obvious whether Master ==
> > >>>>>> bleeding
> > >>>>>>>>> edge,
> > >>>>>>>>>> or
> > >>>>>>>>>>>> Master == Stable version. Using the names "dev" and "stable"
> > >>>>>>> makes
> > >>>>>>>>> it a
> > >>>>>>>>>>> bit
> > >>>>>>>>>>>> clear.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> So... If github forces us to have a default branch, I'm
> > >>>>>> thinking
> > >>>>>>>> that
> > >>>>>>>>>>>> having users send pull requests against "dev" is more
> > >>>>>> valuable
> > >>>>>>> than
> > >>>>>>>>>>> having
> > >>>>>>>>>>>> people download the latest "stable" by default. If people
> are
> > >>>>>>>> pulling
> > >>>>>>>>>>> code
> > >>>>>>>>>>>> from github rather than from our release .zip files, then
> > >>>>>> it's
> > >>>>>>>> likely
> > >>>>>>>>>>> they
> > >>>>>>>>>>>> want to hack on it anyways, or that they want the dev
> > >>>>>> version to
> > >>>>>>>> see
> > >>>>>>>>> if
> > >>>>>>>>>>>> bugs are fixed.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Soo.... Here's version #3! If anyone can think of how to
> > >>>>>> keep the
> > >>>>>>>>> three
> > >>>>>>>>>>>> branches while addressing being forced to have a default
> > >>>>>> branch,
> > >>>>>>>> feel
> > >>>>>>>>>>> free
> > >>>>>>>>>>>> to speak up! :)
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Cordova repositories have two main branches:
> > >>>>>>>>>>>> 1. master
> > >>>>>>>>>>>> 2. next
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Topic branches exist for collaborating on features, or for
> > >>>>>>>>> code-review
> > >>>>>>>>>>>> purposes.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Cordova uses tags to label releases.
> > >>>>>>>>>>>> - Each release candidate has a tag. e.g. "2.2.0rc1"
> > >>>>>>>>>>>> - Each release has a tag. e.g. "2.2.0"
> > >>>>>>>>>>>> - The "latest" tag points to the last stable release (this
> > >>>>>>> follows
> > >>>>>>>>> npm
> > >>>>>>>>>>>> conventions)
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> 1. The "next" branch.
> > >>>>>>>>>>>> - This branch is used only when in the process of doing a
> > >>>>>>> release.
> > >>>>>>>>>>>> - All tags are created from this branch.
> > >>>>>>>>>>>> - All release-candidate bug-fixes are done on this branch.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> 2. The "master" branch.
> > >>>>>>>>>>>> - When not in the release-process, all commits are made here
> > >>>>>>>>>>>> - When in the release-process, all non-bugfix commits are
> > >>>>>> made
> > >>>>>>>> here
> > >>>>>>>>>>>> - This is where topic-branches are merged into.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Cutting a release:
> > >>>>>>>>>>>> 1. git checkout next && git merge --ff-only master
> > >>>>>>>>>>>> 2. Test test test!
> > >>>>>>>>>>>> 3. Fix bugs by committing them directly to "next" and then
> > >>>>>> doing
> > >>>>>>> a
> > >>>>>>>>>> non-ff
> > >>>>>>>>>>>> merge of next into master
> > >>>>>>>>>>>> 4. Tag release candidate
> > >>>>>>>>>>>> 5. Repeat steps 2-4 as necessary
> > >>>>>>>>>>>> 6. Tag the release (both by version and by updating the
> > >>>>>> "latest"
> > >>>>>>>> tag)
> > >>>>>>>>>>>> 7. Create distribution .zip file
> > >>>>>>>>>>>> 8. Test one last time using the dist files
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> Thanks,
> > >>>>>>>>>>>>> Michael
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> On Wed, Jan 23, 2013 at 11:25 AM, Brian LeRoux <b@brian.io
> > >>>>>>>
> > >>>>>>>> wrote:
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>> I'm liking it. Start in 2.5?
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> On Wed, Jan 23, 2013 at 1:19 PM, Filip Maj <fil@adobe.com
> > >>>>>>>
> > >>>>>>>> wrote:
> > >>>>>>>>>>>>>>> Looks great Andrew!
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> If everyone's on board, how are we going to test run
> > >>>>>> this?
> > >>>>>>>> Flip a
> > >>>>>>>>>>>>> switch
> > >>>>>>>>>>>>>>> at a certain point, give it a shot with one repo for one
> > >>>>>> RC?
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> On 1/22/13 12:29 PM, "Andrew Grieve" <
> > >>>>>> agrieve@chromium.org>
> > >>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> Braden, you're right. I've now done some local playing
> > >>>>>>> around
> > >>>>>>>> in
> > >>>>>>>>>>> git,
> > >>>>>>>>>>>>> and
> > >>>>>>>>>>>>>>>> have an updated proposal that uses merges instead of
> > >>>>>>> deleting
> > >>>>>>>>>>>> branches.
> > >>>>>>>>>>>>>>>> PTAL:
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> Cordova repositories have three main branches:
> > >>>>>>>>>>>>>>>> 1. stable
> > >>>>>>>>>>>>>>>> 2. next
> > >>>>>>>>>>>>>>>> 3. dev
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> Topic branches also exist for collaborating on
> > >>>>>> features, or
> > >>>>>>>> for
> > >>>>>>>>>>>>>>>> code-review
> > >>>>>>>>>>>>>>>> purposes.
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> There is *no* master branch, so that community-driven
> > >>>>>> pull
> > >>>>>>>>>> requests
> > >>>>>>>>>>>>> will
> > >>>>>>>>>>>>>>>> be
> > >>>>>>>>>>>>>>>> forced to think about which branch to request against.
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> 1. The "stable" branch.
> > >>>>>>>>>>>>>>>> - Sits at the latest stable release of cordova
> > >>>>>>>>>>>>>>>> - This changes only when doing fast-forward merges from
> > >>>>>>> "next"
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> 2. The "next" branch.
> > >>>>>>>>>>>>>>>> - This branch is used only when in the process of doing
> > >>>>>> a
> > >>>>>>>>> release.
> > >>>>>>>>>>>>>>>> - All tags (both stable and RC) are done on this branch.
> > >>>>>>>>>>>>>>>> - All release-candidate bug-fixes are done on this
> > >>>>>> branch.
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> 3. The "dev" branch.
> > >>>>>>>>>>>>>>>> - This is where non-release-candidate commits are done
> > >>>>>>>>>>>>>>>> - This is where topic-branches are merged into.
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> Cutting a release:
> > >>>>>>>>>>>>>>>> 1. git checkout next && git merge --ff-only dev
> > >>>>>>>>>>>>>>>> 2. Test test test!
> > >>>>>>>>>>>>>>>> 3. Fix bugs by committing them directly to "next" and
> > >>>>>> then
> > >>>>>>>>> doing a
> > >>>>>>>>>>>>> non-ff
> > >>>>>>>>>>>>>>>> merge of next into dev
> > >>>>>>>>>>>>>>>> 4. Tag release candidate
> > >>>>>>>>>>>>>>>> 5. Repeat steps 2-4 as necessary
> > >>>>>>>>>>>>>>>> 6. Tag the release
> > >>>>>>>>>>>>>>>> 7. Create distribution .zip file
> > >>>>>>>>>>>>>>>> 8. Test one last time using the dist files
> > >>>>>>>>>>>>>>>> 9. git checkout stable && git merge --ff-only next
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> On Tue, Jan 22, 2013 at 1:59 PM, Braden Shepherdson
> > >>>>>>>>>>>>>>>> <br...@chromium.org>wrote:
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> I think deleting and recreating branches with the same
> > >>>>>> name
> > >>>>>>>> can
> > >>>>>>>>>>> cause
> > >>>>>>>>>>>>>>>>> badness in git[1] because of remotes. It's not really
> > >>>>>> the
> > >>>>>>>> same
> > >>>>>>>>>>> branch
> > >>>>>>>>>>>>>> in
> > >>>>>>>>>>>>>>>>> terms of commits, and git thinks that your old stable
> > >>>>>> and
> > >>>>>>> the
> > >>>>>>>>> new
> > >>>>>>>>>>>>>> stable
> > >>>>>>>>>>>>>>>>> differ by all of each of their commits. Tags can be
> > >>>>>> moved
> > >>>>>>>>>>>>> arbitrarily,
> > >>>>>>>>>>>>>>>>> so I
> > >>>>>>>>>>>>>>>>> think stable makes sense as a tag. I'm not sure about
> > >>>>>> how
> > >>>>>>>> best
> > >>>>>>>>> to
> > >>>>>>>>>>>>>> handle
> > >>>>>>>>>>>>>>>>> next.
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> [1]
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>
> >
> http://stackoverflow.com/questions/11844581/git-delete-and-recreate-branc
> > >>>>>>>>>>>>>>>>> h
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> On Tue, Jan 22, 2013 at 11:31 AM, Andrew Grieve <
> > >>>>>>>>>>>>> agrieve@chromium.org
> > >>>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> Michal's attending hackathons for the week, and I'm
> > >>>>>> not
> > >>>>>>> sure
> > >>>>>>>>> we
> > >>>>>>>>>>>>> need
> > >>>>>>>>>>>>>>>>> to
> > >>>>>>>>>>>>>>>>> do
> > >>>>>>>>>>>>>>>>>> a hang-out for this, as I think we really are quite
> > >>>>>> close
> > >>>>>>> to
> > >>>>>>>>>>>>>> resolving
> > >>>>>>>>>>>>>>>>>> this. I'd really like to resolve this ASAP so that we
> > >>>>>>> don't
> > >>>>>>>>> need
> > >>>>>>>>>>> to
> > >>>>>>>>>>>>>>>>> have
> > >>>>>>>>>>>>>>>>> a
> > >>>>>>>>>>>>>>>>>> code-freeze for this release.
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> Here's a proposal:
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> Cordova repositories have three main branches:
> > >>>>>>>>>>>>>>>>>> 1. stable
> > >>>>>>>>>>>>>>>>>> 2. next
> > >>>>>>>>>>>>>>>>>> 3. dev
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> Topic branches also exist for collaborating on
> > >>>>>> features,
> > >>>>>>> or
> > >>>>>>>>> for
> > >>>>>>>>>>>>>>>>> code-review
> > >>>>>>>>>>>>>>>>>> purposes.
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> There is *no* master branch, so that community-driven
> > >>>>>> pull
> > >>>>>>>>>>> requests
> > >>>>>>>>>>>>>>>>> will
> > >>>>>>>>>>>>>>>>> be
> > >>>>>>>>>>>>>>>>>> forced to think about which branch to request against.
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> 1. The "stable" branch.
> > >>>>>>>>>>>>>>>>>> - Sits at the latest stable release of cordova
> > >>>>>>>>>>>>>>>>>> - No one ever commits to the "stable" branch. It
> > >>>>>> exists
> > >>>>>>> only
> > >>>>>>>>> as
> > >>>>>>>>>> a
> > >>>>>>>>>>>>>>>>>> short-cut for checking out the latest stable tag.
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> 2. The "next" branch.
> > >>>>>>>>>>>>>>>>>> - This branch exists only when in the process of
> > >>>>>> doing a
> > >>>>>>>>>> release.
> > >>>>>>>>>>>>>>>>>> - All tags (both stable and RC) are done on this
> > >>>>>> branch.
> > >>>>>>>>>>>>>>>>>> - When a stable tag is done:
> > >>>>>>>>>>>>>>>>>> - The existing "stable" branch is deleted
> > >>>>>>>>>>>>>>>>>> - A new "stable" branch is created from "next".
> > >>>>>>>>>>>>>>>>>> - The "next" branch is deleted.
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> 3. The "dev" branch.
> > >>>>>>>>>>>>>>>>>> - This is where all commits are done
> > >>>>>>>>>>>>>>>>>> - This is where topic-branches are merged into.
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> Cutting a release:
> > >>>>>>>>>>>>>>>>>> 1. Create "next" from the HEAD of "dev"
> > >>>>>>>>>>>>>>>>>> 2. Test test test!
> > >>>>>>>>>>>>>>>>>> 3. Fix bugs by committing them to "dev" and then
> > >>>>>>>>> cherry-picking
> > >>>>>>>>>>>>> them
> > >>>>>>>>>>>>>>>>> into
> > >>>>>>>>>>>>>>>>>> "next"
> > >>>>>>>>>>>>>>>>>> 4. Tag release candidate
> > >>>>>>>>>>>>>>>>>> 5. Repeat steps 2-4 as necessary
> > >>>>>>>>>>>>>>>>>> 6. Tag the release
> > >>>>>>>>>>>>>>>>>> 7. Create distribution .zip file
> > >>>>>>>>>>>>>>>>>> 8. Test one last time using the dist files
> > >>>>>>>>>>>>>>>>>> 9. Delete "stable"
> > >>>>>>>>>>>>>>>>>> 10. Create a new "stable" by branching from the HEAD
> > >>>>>> of
> > >>>>>>>> "next"
> > >>>>>>>>>>>>>>>>>> 11. Delete the "next" branch
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> On Wed, Jan 16, 2013 at 10:34 AM, Michal Mocny <
> > >>>>>>>>>>>>> mmocny@chromium.org>
> > >>>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> Just going to throw out one of my personal
> > >>>>>> requirements
> > >>>>>>> for
> > >>>>>>>>>>>>>> whatever
> > >>>>>>>>>>>>>>>>>>> proposal we come up with, so it doesn't get lost:
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> * Feature branches are great for feature work and/or
> > >>>>>>> large
> > >>>>>>>>>>>>> sweeping
> > >>>>>>>>>>>>>>>>>>> changes, as are JIRA bugs for tracking them, but
> > >>>>>> cordova
> > >>>>>>>> has
> > >>>>>>>>>> many
> > >>>>>>>>>>>>>>>>> many
> > >>>>>>>>>>>>>>>>>>> trivial issues that could be fixed with "drive-by"
> > >>>>>>> patches
> > >>>>>>>>> that
> > >>>>>>>>>>>>>>>>> require
> > >>>>>>>>>>>>>>>>>> as
> > >>>>>>>>>>>>>>>>>>> little friction to commit as possible.
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> On Tue, Jan 15, 2013 at 3:05 PM, Marcel Kinard <
> > >>>>>>>>>>>>> cmarcelk@gmail.com
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> How about if there is a specific straw man proposal
> > >>>>>> at
> > >>>>>>> the
> > >>>>>>>>>>>>>>>>> beginning
> > >>>>>>>>>>>>>>>>> of
> > >>>>>>>>>>>>>>>>>>>> the face-time? Then the folks that are in agreement
> > >>>>>>> won't
> > >>>>>>>>> need
> > >>>>>>>>>>>>> to
> > >>>>>>>>>>>>>>>>> say
> > >>>>>>>>>>>>>>>>>>>> anything ;-)
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> Seriously, making adjustments to something tangible
> > >>>>>> is
> > >>>>>>>>> easier
> > >>>>>>>>>>>>>> than
> > >>>>>>>>>>>>>>>>>>>> instantiating it from scratch. A volunteer for a
> > >>>>>> very
> > >>>>>>>> simple
> > >>>>>>>>>>>>>>>>> writeup
> > >>>>>>>>>>>>>>>>> on
> > >>>>>>>>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>>>>> wiki?
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> -- Marcel Kinard
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> On 1/14/2013 10:06 PM, Michal Mocny wrote:
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> Okay gentlemen, I think there have been countless
> > >>>>>> good
> > >>>>>>>>> points
> > >>>>>>>>>>>>>>>>> made
> > >>>>>>>>>>>>>>>>>> from
> > >>>>>>>>>>>>>>>>>>>>> all
> > >>>>>>>>>>>>>>>>>>>>> parties, but also some bike-shedding.
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> Perhaps it is time to schedule some face-time to
> > >>>>>> better
> > >>>>>>>>>>>>>>>>> articulate
> > >>>>>>>>>>>>>>>>>> some
> > >>>>>>>>>>>>>>>>>>> of
> > >>>>>>>>>>>>>>>>>>>>> the finer points, and to help come to some
> > >>>>>> consensus?
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> -Michal
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> --
> > >>>>>>>>>> @purplecabbage
> > >>>>>>>>>> risingj.com
> > >>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> --
> > >>>>>>> @purplecabbage
> > >>>>>>> risingj.com
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>>
> > >>> --
> > >>> @purplecabbage
> > >>> risingj.com
> > >>
> > >>
> >
> >
>
Re: too long to package a release?
Posted by Becky Gibson <gi...@gmail.com>.
Can someone please provide a "git cordova release process for dummies"
example to make sure I do the release commits and merges properly (the
committerWorkflow example didn't help me as I didn't understand the
topic_branch and to_be_merged distinction)
At any rate, can I do a git checkout apache next into my "master" branch?
Then I can checkout my working_branch, rebase master (which contains the
next code) checkout master, merge my fix and push apache next.
git checkout apache next
git checkout working_branch_with_fix
git rebase master
git checkout master
git merge working_branch_with_fix
git push apache next
and then repeat this for apache master with the possibility of needing to
use -ff when I merge. Am I on the right track?
humbled by git,
-becky
On Fri, Feb 8, 2013 at 5:22 PM, Marcel Kinard <cm...@gmail.com> wrote:
> Nice! Thanks, Andrew!
>
> -- Marcel Kinard
>
> On Feb 7, 2013, at 2:59 PM, Andrew Grieve <ag...@chromium.org> wrote:
>
> > The doc's not up-to-date, but I think we ended on consensus for the code
> > version. I've taken a stab at updating the wiki pages:
> >
> > http://wiki.apache.org/cordova/CordovaAndGit -- Added the idea of
> having
> > both a master and a next branch
> > http://wiki.apache.org/cordova/CommitterWorkflow -- Added Jesse's
> version
> > of the "which branch - in code"
> > http://wiki.apache.org/cordova/CuttingReleases -- Changed tagging
> > instructions to refer to the "next" branch
> >
> >
> > On Thu, Feb 7, 2013 at 1:26 PM, Marcel Kinard <cm...@gmail.com>
> wrote:
> >
> >> With 2.5 starting, it appears time to poke this thread.
> >>
> >> - Is the Google doc refreshed with the latest consensus?
> >> - If so, should the Google doc be transferred to a wiki page?
> >> - Have the necessary branches been created?
> >> - Are we all in the boat, and understand how to row this beast?
> >>
> >> -- Marcel Kinard
> >>
> >> On Jan 24, 2013, at 5:14 PM, Jesse <pu...@gmail.com> wrote:
> >>
> >>> Nice Shaz, but I was hoping it was a github style network visualization
> >>> that included a few versions worth of merges.
> >>> Who wants to draw that?
> >>>
> >>> On Thu, Jan 24, 2013 at 2:05 PM, Shazron <sh...@gmail.com> wrote:
> >>>
> >>>> Inline image got mangled, here it is linked: http://cl.ly/MOrD
> >>>>
> >>>>
> >>>> On Thu, Jan 24, 2013 at 1:39 PM, Shazron <sh...@gmail.com> wrote:
> >>>>
> >>>>> Thanks for the pseudocode Andrew, seems simpler to understand ;)
> >> Jesse's
> >>>>> re-factor makes it even easier. Here's my contrib for those more
> >> visually
> >>>>> inclined:
> >>>>>
> >>>>>
> >>>>> [image: Inline image 2]
> >>>>>
> >>>>>
> >>>>> On Thu, Jan 24, 2013 at 1:29 PM, Andrew Grieve <agrieve@chromium.org
> >>> wrote:
> >>>>>
> >>>>>> Nice! even simpler. :)
> >>>>>>
> >>>>>>
> >>>>>> On Thu, Jan 24, 2013 at 3:44 PM, Jesse <pu...@gmail.com>
> >> wrote:
> >>>>>>
> >>>>>>> Thanks for clarifying Andrew. et al, I guess I was
> mis-understanding
> >>>>>> some
> >>>>>>> of the earlier discussion around naming stuff.
> >>>>>>>
> >>>>>>> So everything is going to master all the time, and we only care
> about
> >>>>>>> 'next' if we are inReleaseMode and it is a bug fix?
> >>>>>>>
> >>>>>>> if(inReleaseMode && isBugFix) {
> >>>>>>> commitToBranch('next');
> >>>>>>> mergeBranch('next').into('master');
> >>>>>>> }
> >>>>>>> else {
> >>>>>>> commitToBranch('master');
> >>>>>>> }
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On Thu, Jan 24, 2013 at 12:29 PM, Andrew Grieve <
> >> agrieve@chromium.org
> >>>>>>>> wrote:
> >>>>>>>
> >>>>>>>> Just to clarify - there should be *no* using of the git
> >>>>>> cherry-picking
> >>>>>>>> command, only git merge.
> >>>>>>>>
> >>>>>>>> Jesse - not sure what you're referring to with "branch must be
> named
> >>>>>> x".
> >>>>>>>> The latest revision of the proposal has only two branches: master
> >> and
> >>>>>>> next.
> >>>>>>>> Do you mean you don't like the name "next"?
> >>>>>>>>
> >>>>>>>> Maybe the proposal will seem simpler if put in the form of code :)
> >>>>>>>>
> >>>>>>>> if (!inReleaseMode) {
> >>>>>>>> commitToBranch('master');
> >>>>>>>> } else {
> >>>>>>>> if (isBugFix) {
> >>>>>>>> commitToBranch('next');
> >>>>>>>> mergeBranch('next').into('master');
> >>>>>>>> } else {
> >>>>>>>> commitToBranch('master');
> >>>>>>>> }
> >>>>>>>> }
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Thu, Jan 24, 2013 at 3:06 PM, Braden Shepherdson <
> >>>>>> braden@chromium.org
> >>>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> Most of the time the flow will be unchanged: push to master.
> >>>>>> Tagging
> >>>>>>>> things
> >>>>>>>>> we already know how to do; that doesn't change.
> >>>>>>>>>
> >>>>>>>>> The only new flow for most people is cherrypicking bug fixes from
> >>>>>>> master
> >>>>>>>> to
> >>>>>>>>> next, which we can give examples of. Plus that could remain the
> >>>>>>>>> responsibility of the main platform maintainers, who are doing
> the
> >>>>>>>> tagging.
> >>>>>>>>>
> >>>>>>>>> Braden
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Thu, Jan 24, 2013 at 2:56 PM, Jesse <pu...@gmail.com>
> >>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> On Thu, Jan 24, 2013 at 11:09 AM, Braden Shepherdson <
> >>>>>>>>> braden@chromium.org
> >>>>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> The founding goal we're trying to accomplish here is that we
> >>>>>> don't
> >>>>>>>> want
> >>>>>>>>>>> everyone sitting on changes to be in the next version while we
> >>>>>> use
> >>>>>>>>> master
> >>>>>>>>>>> to prep a release.
> >>>>>>>>>>>
> >>>>>>>>>>> I don't think having one branch for prepping the release and
> >>>>>>> another
> >>>>>>>>> for
> >>>>>>>>>>> main development is a lot of bureaucracy.
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> It is not, the 'branch must be named x' is mainly where I have
> >>>>>>>> concerns.
> >>>>>>>>>> Really I just want things simple.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On Thu, Jan 24, 2013 at 1:57 PM, Jesse MacFadyen <
> >>>>>>>>>> purplecabbage@gmail.com
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> I have been quietly listening on this thread, but thought I
> >>>>>>> should
> >>>>>>>> at
> >>>>>>>>>>>> least share my opinion.
> >>>>>>>>>>>>
> >>>>>>>>>>>> I don't think adding contribution rules helps anyone. Git is
> >>>>>>>>>>>> complicated enough as it is, and this just all seems like
> >>>>>>>>> bureaucracy.
> >>>>>>>>>>>>
> >>>>>>>>>>>> I think master should always contain the latest stable code,
> >>>>>> and
> >>>>>>> be
> >>>>>>>>>>>> periodically tagged with rc's and versions.
> >>>>>>>>>>>> All work should be done in personal forks and feature
> >>>>>> branches.
> >>>>>>>>>>>> If the latest tag of master is an rc, then we should only be
> >>>>>>>> merging
> >>>>>>>>>>>> bugfixes, until the release.
> >>>>>>>>>>>> Immediately after tagging a version we decide which feature
> >>>>>>>> branches
> >>>>>>>>>>>> and pull requests to pull in, and go for it.
> >>>>>>>>>>>>
> >>>>>>>>>>>> I don't think this is much different from what we have, but I
> >>>>>>> think
> >>>>>>>>>>>> that is good.
> >>>>>>>>>>>> The suggestions thus far, while interesting, don't increase
> >>>>>> our
> >>>>>>>>>>>> velocity in my opinion. Also, I can also pretty much guaranty
> >>>>>>> I'll
> >>>>>>>>>>>> screw it up for the next 3-4 versions. ( because I'm dumb )
> >>>>>>>>>>>>
> >>>>>>>>>>>> Cheers,
> >>>>>>>>>>>> Jesse
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> On 2013-01-24, at 5:53 AM, Andrew Grieve <
> >>>>>> agrieve@chromium.org>
> >>>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Wed, Jan 23, 2013 at 4:58 PM, Michael Brooks <
> >>>>>>>>>>> michael@michaelbrooks.ca
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Before we move forward, I have a few questions about the
> >>>>>> "no
> >>>>>>>>> master"
> >>>>>>>>>>>>> approach.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> There is *no* master branch, so that community-driven pull
> >>>>>>>> requests
> >>>>>>>>>>> will
> >>>>>>>>>>>> be
> >>>>>>>>>>>>>> forced to think about which branch to request against.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> - Andrew, can you cite other projects that do not use a
> >>>>>> master
> >>>>>>>>>> branch?
> >>>>>>>>>>>> This project is my first time using git / github, so I don't
> >>>>>> have
> >>>>>>>>> much
> >>>>>>>>>> to
> >>>>>>>>>>>> draw from. I was going off of others' suggestions on this
> >>>>>> thread
> >>>>>>>>> when I
> >>>>>>>>>>>> proposed the names.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>> - On Github, you must have a default branch. If not
> >>>>>> master, it
> >>>>>>>> must
> >>>>>>>>>> be
> >>>>>>>>>>>>> something else. So, users are not forced to think about the
> >>>>>>>> branch
> >>>>>>>>> to
> >>>>>>>>>>>> send
> >>>>>>>>>>>>> a pull request again... they will likely just use the
> >>>>>> default.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Hmm, good point. The goal is to get people downloading
> >>>>>> Cordova
> >>>>>>> for
> >>>>>>>>> use
> >>>>>>>>>> to
> >>>>>>>>>>>> end up with Stable, and for developers to send pull requests
> >>>>>>>> against
> >>>>>>>>>> dev.
> >>>>>>>>>>>> With a forced default branch, I don't think we can accomplish
> >>>>>>> this.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> - Why is the "stable" branch not just "master"?
> >>>>>>>>>>>>
> >>>>>>>>>>>> My thinking was that it's not obvious whether Master ==
> >>>>>> bleeding
> >>>>>>>>> edge,
> >>>>>>>>>> or
> >>>>>>>>>>>> Master == Stable version. Using the names "dev" and "stable"
> >>>>>>> makes
> >>>>>>>>> it a
> >>>>>>>>>>> bit
> >>>>>>>>>>>> clear.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> So... If github forces us to have a default branch, I'm
> >>>>>> thinking
> >>>>>>>> that
> >>>>>>>>>>>> having users send pull requests against "dev" is more
> >>>>>> valuable
> >>>>>>> than
> >>>>>>>>>>> having
> >>>>>>>>>>>> people download the latest "stable" by default. If people are
> >>>>>>>> pulling
> >>>>>>>>>>> code
> >>>>>>>>>>>> from github rather than from our release .zip files, then
> >>>>>> it's
> >>>>>>>> likely
> >>>>>>>>>>> they
> >>>>>>>>>>>> want to hack on it anyways, or that they want the dev
> >>>>>> version to
> >>>>>>>> see
> >>>>>>>>> if
> >>>>>>>>>>>> bugs are fixed.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Soo.... Here's version #3! If anyone can think of how to
> >>>>>> keep the
> >>>>>>>>> three
> >>>>>>>>>>>> branches while addressing being forced to have a default
> >>>>>> branch,
> >>>>>>>> feel
> >>>>>>>>>>> free
> >>>>>>>>>>>> to speak up! :)
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Cordova repositories have two main branches:
> >>>>>>>>>>>> 1. master
> >>>>>>>>>>>> 2. next
> >>>>>>>>>>>>
> >>>>>>>>>>>> Topic branches exist for collaborating on features, or for
> >>>>>>>>> code-review
> >>>>>>>>>>>> purposes.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Cordova uses tags to label releases.
> >>>>>>>>>>>> - Each release candidate has a tag. e.g. "2.2.0rc1"
> >>>>>>>>>>>> - Each release has a tag. e.g. "2.2.0"
> >>>>>>>>>>>> - The "latest" tag points to the last stable release (this
> >>>>>>> follows
> >>>>>>>>> npm
> >>>>>>>>>>>> conventions)
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> 1. The "next" branch.
> >>>>>>>>>>>> - This branch is used only when in the process of doing a
> >>>>>>> release.
> >>>>>>>>>>>> - All tags are created from this branch.
> >>>>>>>>>>>> - All release-candidate bug-fixes are done on this branch.
> >>>>>>>>>>>>
> >>>>>>>>>>>> 2. The "master" branch.
> >>>>>>>>>>>> - When not in the release-process, all commits are made here
> >>>>>>>>>>>> - When in the release-process, all non-bugfix commits are
> >>>>>> made
> >>>>>>>> here
> >>>>>>>>>>>> - This is where topic-branches are merged into.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Cutting a release:
> >>>>>>>>>>>> 1. git checkout next && git merge --ff-only master
> >>>>>>>>>>>> 2. Test test test!
> >>>>>>>>>>>> 3. Fix bugs by committing them directly to "next" and then
> >>>>>> doing
> >>>>>>> a
> >>>>>>>>>> non-ff
> >>>>>>>>>>>> merge of next into master
> >>>>>>>>>>>> 4. Tag release candidate
> >>>>>>>>>>>> 5. Repeat steps 2-4 as necessary
> >>>>>>>>>>>> 6. Tag the release (both by version and by updating the
> >>>>>> "latest"
> >>>>>>>> tag)
> >>>>>>>>>>>> 7. Create distribution .zip file
> >>>>>>>>>>>> 8. Test one last time using the dist files
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>> Michael
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On Wed, Jan 23, 2013 at 11:25 AM, Brian LeRoux <b@brian.io
> >>>>>>>
> >>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> I'm liking it. Start in 2.5?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Wed, Jan 23, 2013 at 1:19 PM, Filip Maj <fil@adobe.com
> >>>>>>>
> >>>>>>>> wrote:
> >>>>>>>>>>>>>>> Looks great Andrew!
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> If everyone's on board, how are we going to test run
> >>>>>> this?
> >>>>>>>> Flip a
> >>>>>>>>>>>>> switch
> >>>>>>>>>>>>>>> at a certain point, give it a shot with one repo for one
> >>>>>> RC?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On 1/22/13 12:29 PM, "Andrew Grieve" <
> >>>>>> agrieve@chromium.org>
> >>>>>>>>> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Braden, you're right. I've now done some local playing
> >>>>>>> around
> >>>>>>>> in
> >>>>>>>>>>> git,
> >>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>> have an updated proposal that uses merges instead of
> >>>>>>> deleting
> >>>>>>>>>>>> branches.
> >>>>>>>>>>>>>>>> PTAL:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Cordova repositories have three main branches:
> >>>>>>>>>>>>>>>> 1. stable
> >>>>>>>>>>>>>>>> 2. next
> >>>>>>>>>>>>>>>> 3. dev
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Topic branches also exist for collaborating on
> >>>>>> features, or
> >>>>>>>> for
> >>>>>>>>>>>>>>>> code-review
> >>>>>>>>>>>>>>>> purposes.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> There is *no* master branch, so that community-driven
> >>>>>> pull
> >>>>>>>>>> requests
> >>>>>>>>>>>>> will
> >>>>>>>>>>>>>>>> be
> >>>>>>>>>>>>>>>> forced to think about which branch to request against.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> 1. The "stable" branch.
> >>>>>>>>>>>>>>>> - Sits at the latest stable release of cordova
> >>>>>>>>>>>>>>>> - This changes only when doing fast-forward merges from
> >>>>>>> "next"
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> 2. The "next" branch.
> >>>>>>>>>>>>>>>> - This branch is used only when in the process of doing
> >>>>>> a
> >>>>>>>>> release.
> >>>>>>>>>>>>>>>> - All tags (both stable and RC) are done on this branch.
> >>>>>>>>>>>>>>>> - All release-candidate bug-fixes are done on this
> >>>>>> branch.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> 3. The "dev" branch.
> >>>>>>>>>>>>>>>> - This is where non-release-candidate commits are done
> >>>>>>>>>>>>>>>> - This is where topic-branches are merged into.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Cutting a release:
> >>>>>>>>>>>>>>>> 1. git checkout next && git merge --ff-only dev
> >>>>>>>>>>>>>>>> 2. Test test test!
> >>>>>>>>>>>>>>>> 3. Fix bugs by committing them directly to "next" and
> >>>>>> then
> >>>>>>>>> doing a
> >>>>>>>>>>>>> non-ff
> >>>>>>>>>>>>>>>> merge of next into dev
> >>>>>>>>>>>>>>>> 4. Tag release candidate
> >>>>>>>>>>>>>>>> 5. Repeat steps 2-4 as necessary
> >>>>>>>>>>>>>>>> 6. Tag the release
> >>>>>>>>>>>>>>>> 7. Create distribution .zip file
> >>>>>>>>>>>>>>>> 8. Test one last time using the dist files
> >>>>>>>>>>>>>>>> 9. git checkout stable && git merge --ff-only next
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On Tue, Jan 22, 2013 at 1:59 PM, Braden Shepherdson
> >>>>>>>>>>>>>>>> <br...@chromium.org>wrote:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> I think deleting and recreating branches with the same
> >>>>>> name
> >>>>>>>> can
> >>>>>>>>>>> cause
> >>>>>>>>>>>>>>>>> badness in git[1] because of remotes. It's not really
> >>>>>> the
> >>>>>>>> same
> >>>>>>>>>>> branch
> >>>>>>>>>>>>>> in
> >>>>>>>>>>>>>>>>> terms of commits, and git thinks that your old stable
> >>>>>> and
> >>>>>>> the
> >>>>>>>>> new
> >>>>>>>>>>>>>> stable
> >>>>>>>>>>>>>>>>> differ by all of each of their commits. Tags can be
> >>>>>> moved
> >>>>>>>>>>>>> arbitrarily,
> >>>>>>>>>>>>>>>>> so I
> >>>>>>>>>>>>>>>>> think stable makes sense as a tag. I'm not sure about
> >>>>>> how
> >>>>>>>> best
> >>>>>>>>> to
> >>>>>>>>>>>>>> handle
> >>>>>>>>>>>>>>>>> next.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> [1]
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>
> http://stackoverflow.com/questions/11844581/git-delete-and-recreate-branc
> >>>>>>>>>>>>>>>>> h
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On Tue, Jan 22, 2013 at 11:31 AM, Andrew Grieve <
> >>>>>>>>>>>>> agrieve@chromium.org
> >>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Michal's attending hackathons for the week, and I'm
> >>>>>> not
> >>>>>>> sure
> >>>>>>>>> we
> >>>>>>>>>>>>> need
> >>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>> do
> >>>>>>>>>>>>>>>>>> a hang-out for this, as I think we really are quite
> >>>>>> close
> >>>>>>> to
> >>>>>>>>>>>>>> resolving
> >>>>>>>>>>>>>>>>>> this. I'd really like to resolve this ASAP so that we
> >>>>>>> don't
> >>>>>>>>> need
> >>>>>>>>>>> to
> >>>>>>>>>>>>>>>>> have
> >>>>>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>>>> code-freeze for this release.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Here's a proposal:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Cordova repositories have three main branches:
> >>>>>>>>>>>>>>>>>> 1. stable
> >>>>>>>>>>>>>>>>>> 2. next
> >>>>>>>>>>>>>>>>>> 3. dev
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Topic branches also exist for collaborating on
> >>>>>> features,
> >>>>>>> or
> >>>>>>>>> for
> >>>>>>>>>>>>>>>>> code-review
> >>>>>>>>>>>>>>>>>> purposes.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> There is *no* master branch, so that community-driven
> >>>>>> pull
> >>>>>>>>>>> requests
> >>>>>>>>>>>>>>>>> will
> >>>>>>>>>>>>>>>>> be
> >>>>>>>>>>>>>>>>>> forced to think about which branch to request against.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> 1. The "stable" branch.
> >>>>>>>>>>>>>>>>>> - Sits at the latest stable release of cordova
> >>>>>>>>>>>>>>>>>> - No one ever commits to the "stable" branch. It
> >>>>>> exists
> >>>>>>> only
> >>>>>>>>> as
> >>>>>>>>>> a
> >>>>>>>>>>>>>>>>>> short-cut for checking out the latest stable tag.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> 2. The "next" branch.
> >>>>>>>>>>>>>>>>>> - This branch exists only when in the process of
> >>>>>> doing a
> >>>>>>>>>> release.
> >>>>>>>>>>>>>>>>>> - All tags (both stable and RC) are done on this
> >>>>>> branch.
> >>>>>>>>>>>>>>>>>> - When a stable tag is done:
> >>>>>>>>>>>>>>>>>> - The existing "stable" branch is deleted
> >>>>>>>>>>>>>>>>>> - A new "stable" branch is created from "next".
> >>>>>>>>>>>>>>>>>> - The "next" branch is deleted.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> 3. The "dev" branch.
> >>>>>>>>>>>>>>>>>> - This is where all commits are done
> >>>>>>>>>>>>>>>>>> - This is where topic-branches are merged into.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Cutting a release:
> >>>>>>>>>>>>>>>>>> 1. Create "next" from the HEAD of "dev"
> >>>>>>>>>>>>>>>>>> 2. Test test test!
> >>>>>>>>>>>>>>>>>> 3. Fix bugs by committing them to "dev" and then
> >>>>>>>>> cherry-picking
> >>>>>>>>>>>>> them
> >>>>>>>>>>>>>>>>> into
> >>>>>>>>>>>>>>>>>> "next"
> >>>>>>>>>>>>>>>>>> 4. Tag release candidate
> >>>>>>>>>>>>>>>>>> 5. Repeat steps 2-4 as necessary
> >>>>>>>>>>>>>>>>>> 6. Tag the release
> >>>>>>>>>>>>>>>>>> 7. Create distribution .zip file
> >>>>>>>>>>>>>>>>>> 8. Test one last time using the dist files
> >>>>>>>>>>>>>>>>>> 9. Delete "stable"
> >>>>>>>>>>>>>>>>>> 10. Create a new "stable" by branching from the HEAD
> >>>>>> of
> >>>>>>>> "next"
> >>>>>>>>>>>>>>>>>> 11. Delete the "next" branch
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On Wed, Jan 16, 2013 at 10:34 AM, Michal Mocny <
> >>>>>>>>>>>>> mmocny@chromium.org>
> >>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Just going to throw out one of my personal
> >>>>>> requirements
> >>>>>>> for
> >>>>>>>>>>>>>> whatever
> >>>>>>>>>>>>>>>>>>> proposal we come up with, so it doesn't get lost:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> * Feature branches are great for feature work and/or
> >>>>>>> large
> >>>>>>>>>>>>> sweeping
> >>>>>>>>>>>>>>>>>>> changes, as are JIRA bugs for tracking them, but
> >>>>>> cordova
> >>>>>>>> has
> >>>>>>>>>> many
> >>>>>>>>>>>>>>>>> many
> >>>>>>>>>>>>>>>>>>> trivial issues that could be fixed with "drive-by"
> >>>>>>> patches
> >>>>>>>>> that
> >>>>>>>>>>>>>>>>> require
> >>>>>>>>>>>>>>>>>> as
> >>>>>>>>>>>>>>>>>>> little friction to commit as possible.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> On Tue, Jan 15, 2013 at 3:05 PM, Marcel Kinard <
> >>>>>>>>>>>>> cmarcelk@gmail.com
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> How about if there is a specific straw man proposal
> >>>>>> at
> >>>>>>> the
> >>>>>>>>>>>>>>>>> beginning
> >>>>>>>>>>>>>>>>> of
> >>>>>>>>>>>>>>>>>>>> the face-time? Then the folks that are in agreement
> >>>>>>> won't
> >>>>>>>>> need
> >>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>> say
> >>>>>>>>>>>>>>>>>>>> anything ;-)
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Seriously, making adjustments to something tangible
> >>>>>> is
> >>>>>>>>> easier
> >>>>>>>>>>>>>> than
> >>>>>>>>>>>>>>>>>>>> instantiating it from scratch. A volunteer for a
> >>>>>> very
> >>>>>>>> simple
> >>>>>>>>>>>>>>>>> writeup
> >>>>>>>>>>>>>>>>> on
> >>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>> wiki?
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> -- Marcel Kinard
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> On 1/14/2013 10:06 PM, Michal Mocny wrote:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Okay gentlemen, I think there have been countless
> >>>>>> good
> >>>>>>>>> points
> >>>>>>>>>>>>>>>>> made
> >>>>>>>>>>>>>>>>>> from
> >>>>>>>>>>>>>>>>>>>>> all
> >>>>>>>>>>>>>>>>>>>>> parties, but also some bike-shedding.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Perhaps it is time to schedule some face-time to
> >>>>>> better
> >>>>>>>>>>>>>>>>> articulate
> >>>>>>>>>>>>>>>>>> some
> >>>>>>>>>>>>>>>>>>> of
> >>>>>>>>>>>>>>>>>>>>> the finer points, and to help come to some
> >>>>>> consensus?
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> -Michal
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> @purplecabbage
> >>>>>>>>>> risingj.com
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> @purplecabbage
> >>>>>>> risingj.com
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> @purplecabbage
> >>> risingj.com
> >>
> >>
>
>
Re: too long to package a release?
Posted by Marcel Kinard <cm...@gmail.com>.
Nice! Thanks, Andrew!
-- Marcel Kinard
On Feb 7, 2013, at 2:59 PM, Andrew Grieve <ag...@chromium.org> wrote:
> The doc's not up-to-date, but I think we ended on consensus for the code
> version. I've taken a stab at updating the wiki pages:
>
> http://wiki.apache.org/cordova/CordovaAndGit -- Added the idea of having
> both a master and a next branch
> http://wiki.apache.org/cordova/CommitterWorkflow -- Added Jesse's version
> of the "which branch - in code"
> http://wiki.apache.org/cordova/CuttingReleases -- Changed tagging
> instructions to refer to the "next" branch
>
>
> On Thu, Feb 7, 2013 at 1:26 PM, Marcel Kinard <cm...@gmail.com> wrote:
>
>> With 2.5 starting, it appears time to poke this thread.
>>
>> - Is the Google doc refreshed with the latest consensus?
>> - If so, should the Google doc be transferred to a wiki page?
>> - Have the necessary branches been created?
>> - Are we all in the boat, and understand how to row this beast?
>>
>> -- Marcel Kinard
>>
>> On Jan 24, 2013, at 5:14 PM, Jesse <pu...@gmail.com> wrote:
>>
>>> Nice Shaz, but I was hoping it was a github style network visualization
>>> that included a few versions worth of merges.
>>> Who wants to draw that?
>>>
>>> On Thu, Jan 24, 2013 at 2:05 PM, Shazron <sh...@gmail.com> wrote:
>>>
>>>> Inline image got mangled, here it is linked: http://cl.ly/MOrD
>>>>
>>>>
>>>> On Thu, Jan 24, 2013 at 1:39 PM, Shazron <sh...@gmail.com> wrote:
>>>>
>>>>> Thanks for the pseudocode Andrew, seems simpler to understand ;)
>> Jesse's
>>>>> re-factor makes it even easier. Here's my contrib for those more
>> visually
>>>>> inclined:
>>>>>
>>>>>
>>>>> [image: Inline image 2]
>>>>>
>>>>>
>>>>> On Thu, Jan 24, 2013 at 1:29 PM, Andrew Grieve <agrieve@chromium.org
>>> wrote:
>>>>>
>>>>>> Nice! even simpler. :)
>>>>>>
>>>>>>
>>>>>> On Thu, Jan 24, 2013 at 3:44 PM, Jesse <pu...@gmail.com>
>> wrote:
>>>>>>
>>>>>>> Thanks for clarifying Andrew. et al, I guess I was mis-understanding
>>>>>> some
>>>>>>> of the earlier discussion around naming stuff.
>>>>>>>
>>>>>>> So everything is going to master all the time, and we only care about
>>>>>>> 'next' if we are inReleaseMode and it is a bug fix?
>>>>>>>
>>>>>>> if(inReleaseMode && isBugFix) {
>>>>>>> commitToBranch('next');
>>>>>>> mergeBranch('next').into('master');
>>>>>>> }
>>>>>>> else {
>>>>>>> commitToBranch('master');
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Jan 24, 2013 at 12:29 PM, Andrew Grieve <
>> agrieve@chromium.org
>>>>>>>> wrote:
>>>>>>>
>>>>>>>> Just to clarify - there should be *no* using of the git
>>>>>> cherry-picking
>>>>>>>> command, only git merge.
>>>>>>>>
>>>>>>>> Jesse - not sure what you're referring to with "branch must be named
>>>>>> x".
>>>>>>>> The latest revision of the proposal has only two branches: master
>> and
>>>>>>> next.
>>>>>>>> Do you mean you don't like the name "next"?
>>>>>>>>
>>>>>>>> Maybe the proposal will seem simpler if put in the form of code :)
>>>>>>>>
>>>>>>>> if (!inReleaseMode) {
>>>>>>>> commitToBranch('master');
>>>>>>>> } else {
>>>>>>>> if (isBugFix) {
>>>>>>>> commitToBranch('next');
>>>>>>>> mergeBranch('next').into('master');
>>>>>>>> } else {
>>>>>>>> commitToBranch('master');
>>>>>>>> }
>>>>>>>> }
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Jan 24, 2013 at 3:06 PM, Braden Shepherdson <
>>>>>> braden@chromium.org
>>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Most of the time the flow will be unchanged: push to master.
>>>>>> Tagging
>>>>>>>> things
>>>>>>>>> we already know how to do; that doesn't change.
>>>>>>>>>
>>>>>>>>> The only new flow for most people is cherrypicking bug fixes from
>>>>>>> master
>>>>>>>> to
>>>>>>>>> next, which we can give examples of. Plus that could remain the
>>>>>>>>> responsibility of the main platform maintainers, who are doing the
>>>>>>>> tagging.
>>>>>>>>>
>>>>>>>>> Braden
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Jan 24, 2013 at 2:56 PM, Jesse <pu...@gmail.com>
>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> On Thu, Jan 24, 2013 at 11:09 AM, Braden Shepherdson <
>>>>>>>>> braden@chromium.org
>>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> The founding goal we're trying to accomplish here is that we
>>>>>> don't
>>>>>>>> want
>>>>>>>>>>> everyone sitting on changes to be in the next version while we
>>>>>> use
>>>>>>>>> master
>>>>>>>>>>> to prep a release.
>>>>>>>>>>>
>>>>>>>>>>> I don't think having one branch for prepping the release and
>>>>>>> another
>>>>>>>>> for
>>>>>>>>>>> main development is a lot of bureaucracy.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> It is not, the 'branch must be named x' is mainly where I have
>>>>>>>> concerns.
>>>>>>>>>> Really I just want things simple.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Jan 24, 2013 at 1:57 PM, Jesse MacFadyen <
>>>>>>>>>> purplecabbage@gmail.com
>>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> I have been quietly listening on this thread, but thought I
>>>>>>> should
>>>>>>>> at
>>>>>>>>>>>> least share my opinion.
>>>>>>>>>>>>
>>>>>>>>>>>> I don't think adding contribution rules helps anyone. Git is
>>>>>>>>>>>> complicated enough as it is, and this just all seems like
>>>>>>>>> bureaucracy.
>>>>>>>>>>>>
>>>>>>>>>>>> I think master should always contain the latest stable code,
>>>>>> and
>>>>>>> be
>>>>>>>>>>>> periodically tagged with rc's and versions.
>>>>>>>>>>>> All work should be done in personal forks and feature
>>>>>> branches.
>>>>>>>>>>>> If the latest tag of master is an rc, then we should only be
>>>>>>>> merging
>>>>>>>>>>>> bugfixes, until the release.
>>>>>>>>>>>> Immediately after tagging a version we decide which feature
>>>>>>>> branches
>>>>>>>>>>>> and pull requests to pull in, and go for it.
>>>>>>>>>>>>
>>>>>>>>>>>> I don't think this is much different from what we have, but I
>>>>>>> think
>>>>>>>>>>>> that is good.
>>>>>>>>>>>> The suggestions thus far, while interesting, don't increase
>>>>>> our
>>>>>>>>>>>> velocity in my opinion. Also, I can also pretty much guaranty
>>>>>>> I'll
>>>>>>>>>>>> screw it up for the next 3-4 versions. ( because I'm dumb )
>>>>>>>>>>>>
>>>>>>>>>>>> Cheers,
>>>>>>>>>>>> Jesse
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 2013-01-24, at 5:53 AM, Andrew Grieve <
>>>>>> agrieve@chromium.org>
>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, Jan 23, 2013 at 4:58 PM, Michael Brooks <
>>>>>>>>>>> michael@michaelbrooks.ca
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Before we move forward, I have a few questions about the
>>>>>> "no
>>>>>>>>> master"
>>>>>>>>>>>>> approach.
>>>>>>>>>>>>>
>>>>>>>>>>>>> There is *no* master branch, so that community-driven pull
>>>>>>>> requests
>>>>>>>>>>> will
>>>>>>>>>>>> be
>>>>>>>>>>>>>> forced to think about which branch to request against.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> - Andrew, can you cite other projects that do not use a
>>>>>> master
>>>>>>>>>> branch?
>>>>>>>>>>>> This project is my first time using git / github, so I don't
>>>>>> have
>>>>>>>>> much
>>>>>>>>>> to
>>>>>>>>>>>> draw from. I was going off of others' suggestions on this
>>>>>> thread
>>>>>>>>> when I
>>>>>>>>>>>> proposed the names.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> - On Github, you must have a default branch. If not
>>>>>> master, it
>>>>>>>> must
>>>>>>>>>> be
>>>>>>>>>>>>> something else. So, users are not forced to think about the
>>>>>>>> branch
>>>>>>>>> to
>>>>>>>>>>>> send
>>>>>>>>>>>>> a pull request again... they will likely just use the
>>>>>> default.
>>>>>>>>>>>>
>>>>>>>>>>>> Hmm, good point. The goal is to get people downloading
>>>>>> Cordova
>>>>>>> for
>>>>>>>>> use
>>>>>>>>>> to
>>>>>>>>>>>> end up with Stable, and for developers to send pull requests
>>>>>>>> against
>>>>>>>>>> dev.
>>>>>>>>>>>> With a forced default branch, I don't think we can accomplish
>>>>>>> this.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> - Why is the "stable" branch not just "master"?
>>>>>>>>>>>>
>>>>>>>>>>>> My thinking was that it's not obvious whether Master ==
>>>>>> bleeding
>>>>>>>>> edge,
>>>>>>>>>> or
>>>>>>>>>>>> Master == Stable version. Using the names "dev" and "stable"
>>>>>>> makes
>>>>>>>>> it a
>>>>>>>>>>> bit
>>>>>>>>>>>> clear.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> So... If github forces us to have a default branch, I'm
>>>>>> thinking
>>>>>>>> that
>>>>>>>>>>>> having users send pull requests against "dev" is more
>>>>>> valuable
>>>>>>> than
>>>>>>>>>>> having
>>>>>>>>>>>> people download the latest "stable" by default. If people are
>>>>>>>> pulling
>>>>>>>>>>> code
>>>>>>>>>>>> from github rather than from our release .zip files, then
>>>>>> it's
>>>>>>>> likely
>>>>>>>>>>> they
>>>>>>>>>>>> want to hack on it anyways, or that they want the dev
>>>>>> version to
>>>>>>>> see
>>>>>>>>> if
>>>>>>>>>>>> bugs are fixed.
>>>>>>>>>>>>
>>>>>>>>>>>> Soo.... Here's version #3! If anyone can think of how to
>>>>>> keep the
>>>>>>>>> three
>>>>>>>>>>>> branches while addressing being forced to have a default
>>>>>> branch,
>>>>>>>> feel
>>>>>>>>>>> free
>>>>>>>>>>>> to speak up! :)
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Cordova repositories have two main branches:
>>>>>>>>>>>> 1. master
>>>>>>>>>>>> 2. next
>>>>>>>>>>>>
>>>>>>>>>>>> Topic branches exist for collaborating on features, or for
>>>>>>>>> code-review
>>>>>>>>>>>> purposes.
>>>>>>>>>>>>
>>>>>>>>>>>> Cordova uses tags to label releases.
>>>>>>>>>>>> - Each release candidate has a tag. e.g. "2.2.0rc1"
>>>>>>>>>>>> - Each release has a tag. e.g. "2.2.0"
>>>>>>>>>>>> - The "latest" tag points to the last stable release (this
>>>>>>> follows
>>>>>>>>> npm
>>>>>>>>>>>> conventions)
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 1. The "next" branch.
>>>>>>>>>>>> - This branch is used only when in the process of doing a
>>>>>>> release.
>>>>>>>>>>>> - All tags are created from this branch.
>>>>>>>>>>>> - All release-candidate bug-fixes are done on this branch.
>>>>>>>>>>>>
>>>>>>>>>>>> 2. The "master" branch.
>>>>>>>>>>>> - When not in the release-process, all commits are made here
>>>>>>>>>>>> - When in the release-process, all non-bugfix commits are
>>>>>> made
>>>>>>>> here
>>>>>>>>>>>> - This is where topic-branches are merged into.
>>>>>>>>>>>>
>>>>>>>>>>>> Cutting a release:
>>>>>>>>>>>> 1. git checkout next && git merge --ff-only master
>>>>>>>>>>>> 2. Test test test!
>>>>>>>>>>>> 3. Fix bugs by committing them directly to "next" and then
>>>>>> doing
>>>>>>> a
>>>>>>>>>> non-ff
>>>>>>>>>>>> merge of next into master
>>>>>>>>>>>> 4. Tag release candidate
>>>>>>>>>>>> 5. Repeat steps 2-4 as necessary
>>>>>>>>>>>> 6. Tag the release (both by version and by updating the
>>>>>> "latest"
>>>>>>>> tag)
>>>>>>>>>>>> 7. Create distribution .zip file
>>>>>>>>>>>> 8. Test one last time using the dist files
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Michael
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Wed, Jan 23, 2013 at 11:25 AM, Brian LeRoux <b@brian.io
>>>>>>>
>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'm liking it. Start in 2.5?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Wed, Jan 23, 2013 at 1:19 PM, Filip Maj <fil@adobe.com
>>>>>>>
>>>>>>>> wrote:
>>>>>>>>>>>>>>> Looks great Andrew!
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If everyone's on board, how are we going to test run
>>>>>> this?
>>>>>>>> Flip a
>>>>>>>>>>>>> switch
>>>>>>>>>>>>>>> at a certain point, give it a shot with one repo for one
>>>>>> RC?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 1/22/13 12:29 PM, "Andrew Grieve" <
>>>>>> agrieve@chromium.org>
>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Braden, you're right. I've now done some local playing
>>>>>>> around
>>>>>>>> in
>>>>>>>>>>> git,
>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>> have an updated proposal that uses merges instead of
>>>>>>> deleting
>>>>>>>>>>>> branches.
>>>>>>>>>>>>>>>> PTAL:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Cordova repositories have three main branches:
>>>>>>>>>>>>>>>> 1. stable
>>>>>>>>>>>>>>>> 2. next
>>>>>>>>>>>>>>>> 3. dev
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Topic branches also exist for collaborating on
>>>>>> features, or
>>>>>>>> for
>>>>>>>>>>>>>>>> code-review
>>>>>>>>>>>>>>>> purposes.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> There is *no* master branch, so that community-driven
>>>>>> pull
>>>>>>>>>> requests
>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>> forced to think about which branch to request against.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 1. The "stable" branch.
>>>>>>>>>>>>>>>> - Sits at the latest stable release of cordova
>>>>>>>>>>>>>>>> - This changes only when doing fast-forward merges from
>>>>>>> "next"
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 2. The "next" branch.
>>>>>>>>>>>>>>>> - This branch is used only when in the process of doing
>>>>>> a
>>>>>>>>> release.
>>>>>>>>>>>>>>>> - All tags (both stable and RC) are done on this branch.
>>>>>>>>>>>>>>>> - All release-candidate bug-fixes are done on this
>>>>>> branch.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 3. The "dev" branch.
>>>>>>>>>>>>>>>> - This is where non-release-candidate commits are done
>>>>>>>>>>>>>>>> - This is where topic-branches are merged into.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Cutting a release:
>>>>>>>>>>>>>>>> 1. git checkout next && git merge --ff-only dev
>>>>>>>>>>>>>>>> 2. Test test test!
>>>>>>>>>>>>>>>> 3. Fix bugs by committing them directly to "next" and
>>>>>> then
>>>>>>>>> doing a
>>>>>>>>>>>>> non-ff
>>>>>>>>>>>>>>>> merge of next into dev
>>>>>>>>>>>>>>>> 4. Tag release candidate
>>>>>>>>>>>>>>>> 5. Repeat steps 2-4 as necessary
>>>>>>>>>>>>>>>> 6. Tag the release
>>>>>>>>>>>>>>>> 7. Create distribution .zip file
>>>>>>>>>>>>>>>> 8. Test one last time using the dist files
>>>>>>>>>>>>>>>> 9. git checkout stable && git merge --ff-only next
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Tue, Jan 22, 2013 at 1:59 PM, Braden Shepherdson
>>>>>>>>>>>>>>>> <br...@chromium.org>wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I think deleting and recreating branches with the same
>>>>>> name
>>>>>>>> can
>>>>>>>>>>> cause
>>>>>>>>>>>>>>>>> badness in git[1] because of remotes. It's not really
>>>>>> the
>>>>>>>> same
>>>>>>>>>>> branch
>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>> terms of commits, and git thinks that your old stable
>>>>>> and
>>>>>>> the
>>>>>>>>> new
>>>>>>>>>>>>>> stable
>>>>>>>>>>>>>>>>> differ by all of each of their commits. Tags can be
>>>>>> moved
>>>>>>>>>>>>> arbitrarily,
>>>>>>>>>>>>>>>>> so I
>>>>>>>>>>>>>>>>> think stable makes sense as a tag. I'm not sure about
>>>>>> how
>>>>>>>> best
>>>>>>>>> to
>>>>>>>>>>>>>> handle
>>>>>>>>>>>>>>>>> next.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> [1]
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>> http://stackoverflow.com/questions/11844581/git-delete-and-recreate-branc
>>>>>>>>>>>>>>>>> h
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Tue, Jan 22, 2013 at 11:31 AM, Andrew Grieve <
>>>>>>>>>>>>> agrieve@chromium.org
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Michal's attending hackathons for the week, and I'm
>>>>>> not
>>>>>>> sure
>>>>>>>>> we
>>>>>>>>>>>>> need
>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>> do
>>>>>>>>>>>>>>>>>> a hang-out for this, as I think we really are quite
>>>>>> close
>>>>>>> to
>>>>>>>>>>>>>> resolving
>>>>>>>>>>>>>>>>>> this. I'd really like to resolve this ASAP so that we
>>>>>>> don't
>>>>>>>>> need
>>>>>>>>>>> to
>>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>> code-freeze for this release.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Here's a proposal:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Cordova repositories have three main branches:
>>>>>>>>>>>>>>>>>> 1. stable
>>>>>>>>>>>>>>>>>> 2. next
>>>>>>>>>>>>>>>>>> 3. dev
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Topic branches also exist for collaborating on
>>>>>> features,
>>>>>>> or
>>>>>>>>> for
>>>>>>>>>>>>>>>>> code-review
>>>>>>>>>>>>>>>>>> purposes.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> There is *no* master branch, so that community-driven
>>>>>> pull
>>>>>>>>>>> requests
>>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>> forced to think about which branch to request against.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 1. The "stable" branch.
>>>>>>>>>>>>>>>>>> - Sits at the latest stable release of cordova
>>>>>>>>>>>>>>>>>> - No one ever commits to the "stable" branch. It
>>>>>> exists
>>>>>>> only
>>>>>>>>> as
>>>>>>>>>> a
>>>>>>>>>>>>>>>>>> short-cut for checking out the latest stable tag.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 2. The "next" branch.
>>>>>>>>>>>>>>>>>> - This branch exists only when in the process of
>>>>>> doing a
>>>>>>>>>> release.
>>>>>>>>>>>>>>>>>> - All tags (both stable and RC) are done on this
>>>>>> branch.
>>>>>>>>>>>>>>>>>> - When a stable tag is done:
>>>>>>>>>>>>>>>>>> - The existing "stable" branch is deleted
>>>>>>>>>>>>>>>>>> - A new "stable" branch is created from "next".
>>>>>>>>>>>>>>>>>> - The "next" branch is deleted.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 3. The "dev" branch.
>>>>>>>>>>>>>>>>>> - This is where all commits are done
>>>>>>>>>>>>>>>>>> - This is where topic-branches are merged into.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Cutting a release:
>>>>>>>>>>>>>>>>>> 1. Create "next" from the HEAD of "dev"
>>>>>>>>>>>>>>>>>> 2. Test test test!
>>>>>>>>>>>>>>>>>> 3. Fix bugs by committing them to "dev" and then
>>>>>>>>> cherry-picking
>>>>>>>>>>>>> them
>>>>>>>>>>>>>>>>> into
>>>>>>>>>>>>>>>>>> "next"
>>>>>>>>>>>>>>>>>> 4. Tag release candidate
>>>>>>>>>>>>>>>>>> 5. Repeat steps 2-4 as necessary
>>>>>>>>>>>>>>>>>> 6. Tag the release
>>>>>>>>>>>>>>>>>> 7. Create distribution .zip file
>>>>>>>>>>>>>>>>>> 8. Test one last time using the dist files
>>>>>>>>>>>>>>>>>> 9. Delete "stable"
>>>>>>>>>>>>>>>>>> 10. Create a new "stable" by branching from the HEAD
>>>>>> of
>>>>>>>> "next"
>>>>>>>>>>>>>>>>>> 11. Delete the "next" branch
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Wed, Jan 16, 2013 at 10:34 AM, Michal Mocny <
>>>>>>>>>>>>> mmocny@chromium.org>
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Just going to throw out one of my personal
>>>>>> requirements
>>>>>>> for
>>>>>>>>>>>>>> whatever
>>>>>>>>>>>>>>>>>>> proposal we come up with, so it doesn't get lost:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> * Feature branches are great for feature work and/or
>>>>>>> large
>>>>>>>>>>>>> sweeping
>>>>>>>>>>>>>>>>>>> changes, as are JIRA bugs for tracking them, but
>>>>>> cordova
>>>>>>>> has
>>>>>>>>>> many
>>>>>>>>>>>>>>>>> many
>>>>>>>>>>>>>>>>>>> trivial issues that could be fixed with "drive-by"
>>>>>>> patches
>>>>>>>>> that
>>>>>>>>>>>>>>>>> require
>>>>>>>>>>>>>>>>>> as
>>>>>>>>>>>>>>>>>>> little friction to commit as possible.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Tue, Jan 15, 2013 at 3:05 PM, Marcel Kinard <
>>>>>>>>>>>>> cmarcelk@gmail.com
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> How about if there is a specific straw man proposal
>>>>>> at
>>>>>>> the
>>>>>>>>>>>>>>>>> beginning
>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>>>> the face-time? Then the folks that are in agreement
>>>>>>> won't
>>>>>>>>> need
>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>> say
>>>>>>>>>>>>>>>>>>>> anything ;-)
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Seriously, making adjustments to something tangible
>>>>>> is
>>>>>>>>> easier
>>>>>>>>>>>>>> than
>>>>>>>>>>>>>>>>>>>> instantiating it from scratch. A volunteer for a
>>>>>> very
>>>>>>>> simple
>>>>>>>>>>>>>>>>> writeup
>>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> wiki?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> -- Marcel Kinard
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 1/14/2013 10:06 PM, Michal Mocny wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Okay gentlemen, I think there have been countless
>>>>>> good
>>>>>>>>> points
>>>>>>>>>>>>>>>>> made
>>>>>>>>>>>>>>>>>> from
>>>>>>>>>>>>>>>>>>>>> all
>>>>>>>>>>>>>>>>>>>>> parties, but also some bike-shedding.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Perhaps it is time to schedule some face-time to
>>>>>> better
>>>>>>>>>>>>>>>>> articulate
>>>>>>>>>>>>>>>>>> some
>>>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>>>>> the finer points, and to help come to some
>>>>>> consensus?
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> -Michal
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> @purplecabbage
>>>>>>>>>> risingj.com
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> @purplecabbage
>>>>>>> risingj.com
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> @purplecabbage
>>> risingj.com
>>
>>
Re: too long to package a release?
Posted by Andrew Grieve <ag...@chromium.org>.
The doc's not up-to-date, but I think we ended on consensus for the code
version. I've taken a stab at updating the wiki pages:
http://wiki.apache.org/cordova/CordovaAndGit -- Added the idea of having
both a master and a next branch
http://wiki.apache.org/cordova/CommitterWorkflow -- Added Jesse's version
of the "which branch - in code"
http://wiki.apache.org/cordova/CuttingReleases -- Changed tagging
instructions to refer to the "next" branch
On Thu, Feb 7, 2013 at 1:26 PM, Marcel Kinard <cm...@gmail.com> wrote:
> With 2.5 starting, it appears time to poke this thread.
>
> - Is the Google doc refreshed with the latest consensus?
> - If so, should the Google doc be transferred to a wiki page?
> - Have the necessary branches been created?
> - Are we all in the boat, and understand how to row this beast?
>
> -- Marcel Kinard
>
> On Jan 24, 2013, at 5:14 PM, Jesse <pu...@gmail.com> wrote:
>
> > Nice Shaz, but I was hoping it was a github style network visualization
> > that included a few versions worth of merges.
> > Who wants to draw that?
> >
> > On Thu, Jan 24, 2013 at 2:05 PM, Shazron <sh...@gmail.com> wrote:
> >
> >> Inline image got mangled, here it is linked: http://cl.ly/MOrD
> >>
> >>
> >> On Thu, Jan 24, 2013 at 1:39 PM, Shazron <sh...@gmail.com> wrote:
> >>
> >>> Thanks for the pseudocode Andrew, seems simpler to understand ;)
> Jesse's
> >>> re-factor makes it even easier. Here's my contrib for those more
> visually
> >>> inclined:
> >>>
> >>>
> >>> [image: Inline image 2]
> >>>
> >>>
> >>> On Thu, Jan 24, 2013 at 1:29 PM, Andrew Grieve <agrieve@chromium.org
> >wrote:
> >>>
> >>>> Nice! even simpler. :)
> >>>>
> >>>>
> >>>> On Thu, Jan 24, 2013 at 3:44 PM, Jesse <pu...@gmail.com>
> wrote:
> >>>>
> >>>>> Thanks for clarifying Andrew. et al, I guess I was mis-understanding
> >>>> some
> >>>>> of the earlier discussion around naming stuff.
> >>>>>
> >>>>> So everything is going to master all the time, and we only care about
> >>>>> 'next' if we are inReleaseMode and it is a bug fix?
> >>>>>
> >>>>> if(inReleaseMode && isBugFix) {
> >>>>> commitToBranch('next');
> >>>>> mergeBranch('next').into('master');
> >>>>> }
> >>>>> else {
> >>>>> commitToBranch('master');
> >>>>> }
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Thu, Jan 24, 2013 at 12:29 PM, Andrew Grieve <
> agrieve@chromium.org
> >>>>>> wrote:
> >>>>>
> >>>>>> Just to clarify - there should be *no* using of the git
> >>>> cherry-picking
> >>>>>> command, only git merge.
> >>>>>>
> >>>>>> Jesse - not sure what you're referring to with "branch must be named
> >>>> x".
> >>>>>> The latest revision of the proposal has only two branches: master
> and
> >>>>> next.
> >>>>>> Do you mean you don't like the name "next"?
> >>>>>>
> >>>>>> Maybe the proposal will seem simpler if put in the form of code :)
> >>>>>>
> >>>>>> if (!inReleaseMode) {
> >>>>>> commitToBranch('master');
> >>>>>> } else {
> >>>>>> if (isBugFix) {
> >>>>>> commitToBranch('next');
> >>>>>> mergeBranch('next').into('master');
> >>>>>> } else {
> >>>>>> commitToBranch('master');
> >>>>>> }
> >>>>>> }
> >>>>>>
> >>>>>>
> >>>>>> On Thu, Jan 24, 2013 at 3:06 PM, Braden Shepherdson <
> >>>> braden@chromium.org
> >>>>>>> wrote:
> >>>>>>
> >>>>>>> Most of the time the flow will be unchanged: push to master.
> >>>> Tagging
> >>>>>> things
> >>>>>>> we already know how to do; that doesn't change.
> >>>>>>>
> >>>>>>> The only new flow for most people is cherrypicking bug fixes from
> >>>>> master
> >>>>>> to
> >>>>>>> next, which we can give examples of. Plus that could remain the
> >>>>>>> responsibility of the main platform maintainers, who are doing the
> >>>>>> tagging.
> >>>>>>>
> >>>>>>> Braden
> >>>>>>>
> >>>>>>>
> >>>>>>> On Thu, Jan 24, 2013 at 2:56 PM, Jesse <pu...@gmail.com>
> >>>>> wrote:
> >>>>>>>
> >>>>>>>> On Thu, Jan 24, 2013 at 11:09 AM, Braden Shepherdson <
> >>>>>>> braden@chromium.org
> >>>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> The founding goal we're trying to accomplish here is that we
> >>>> don't
> >>>>>> want
> >>>>>>>>> everyone sitting on changes to be in the next version while we
> >>>> use
> >>>>>>> master
> >>>>>>>>> to prep a release.
> >>>>>>>>>
> >>>>>>>>> I don't think having one branch for prepping the release and
> >>>>> another
> >>>>>>> for
> >>>>>>>>> main development is a lot of bureaucracy.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> It is not, the 'branch must be named x' is mainly where I have
> >>>>>> concerns.
> >>>>>>>> Really I just want things simple.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Thu, Jan 24, 2013 at 1:57 PM, Jesse MacFadyen <
> >>>>>>>> purplecabbage@gmail.com
> >>>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> I have been quietly listening on this thread, but thought I
> >>>>> should
> >>>>>> at
> >>>>>>>>>> least share my opinion.
> >>>>>>>>>>
> >>>>>>>>>> I don't think adding contribution rules helps anyone. Git is
> >>>>>>>>>> complicated enough as it is, and this just all seems like
> >>>>>>> bureaucracy.
> >>>>>>>>>>
> >>>>>>>>>> I think master should always contain the latest stable code,
> >>>> and
> >>>>> be
> >>>>>>>>>> periodically tagged with rc's and versions.
> >>>>>>>>>> All work should be done in personal forks and feature
> >>>> branches.
> >>>>>>>>>> If the latest tag of master is an rc, then we should only be
> >>>>>> merging
> >>>>>>>>>> bugfixes, until the release.
> >>>>>>>>>> Immediately after tagging a version we decide which feature
> >>>>>> branches
> >>>>>>>>>> and pull requests to pull in, and go for it.
> >>>>>>>>>>
> >>>>>>>>>> I don't think this is much different from what we have, but I
> >>>>> think
> >>>>>>>>>> that is good.
> >>>>>>>>>> The suggestions thus far, while interesting, don't increase
> >>>> our
> >>>>>>>>>> velocity in my opinion. Also, I can also pretty much guaranty
> >>>>> I'll
> >>>>>>>>>> screw it up for the next 3-4 versions. ( because I'm dumb )
> >>>>>>>>>>
> >>>>>>>>>> Cheers,
> >>>>>>>>>> Jesse
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On 2013-01-24, at 5:53 AM, Andrew Grieve <
> >>>> agrieve@chromium.org>
> >>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>> On Wed, Jan 23, 2013 at 4:58 PM, Michael Brooks <
> >>>>>>>>> michael@michaelbrooks.ca
> >>>>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> Before we move forward, I have a few questions about the
> >>>> "no
> >>>>>>> master"
> >>>>>>>>>>> approach.
> >>>>>>>>>>>
> >>>>>>>>>>> There is *no* master branch, so that community-driven pull
> >>>>>> requests
> >>>>>>>>> will
> >>>>>>>>>> be
> >>>>>>>>>>>> forced to think about which branch to request against.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> - Andrew, can you cite other projects that do not use a
> >>>> master
> >>>>>>>> branch?
> >>>>>>>>>> This project is my first time using git / github, so I don't
> >>>> have
> >>>>>>> much
> >>>>>>>> to
> >>>>>>>>>> draw from. I was going off of others' suggestions on this
> >>>> thread
> >>>>>>> when I
> >>>>>>>>>> proposed the names.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> - On Github, you must have a default branch. If not
> >>>> master, it
> >>>>>> must
> >>>>>>>> be
> >>>>>>>>>>> something else. So, users are not forced to think about the
> >>>>>> branch
> >>>>>>> to
> >>>>>>>>>> send
> >>>>>>>>>>> a pull request again... they will likely just use the
> >>>> default.
> >>>>>>>>>>
> >>>>>>>>>> Hmm, good point. The goal is to get people downloading
> >>>> Cordova
> >>>>> for
> >>>>>>> use
> >>>>>>>> to
> >>>>>>>>>> end up with Stable, and for developers to send pull requests
> >>>>>> against
> >>>>>>>> dev.
> >>>>>>>>>> With a forced default branch, I don't think we can accomplish
> >>>>> this.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> - Why is the "stable" branch not just "master"?
> >>>>>>>>>>
> >>>>>>>>>> My thinking was that it's not obvious whether Master ==
> >>>> bleeding
> >>>>>>> edge,
> >>>>>>>> or
> >>>>>>>>>> Master == Stable version. Using the names "dev" and "stable"
> >>>>> makes
> >>>>>>> it a
> >>>>>>>>> bit
> >>>>>>>>>> clear.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> So... If github forces us to have a default branch, I'm
> >>>> thinking
> >>>>>> that
> >>>>>>>>>> having users send pull requests against "dev" is more
> >>>> valuable
> >>>>> than
> >>>>>>>>> having
> >>>>>>>>>> people download the latest "stable" by default. If people are
> >>>>>> pulling
> >>>>>>>>> code
> >>>>>>>>>> from github rather than from our release .zip files, then
> >>>> it's
> >>>>>> likely
> >>>>>>>>> they
> >>>>>>>>>> want to hack on it anyways, or that they want the dev
> >>>> version to
> >>>>>> see
> >>>>>>> if
> >>>>>>>>>> bugs are fixed.
> >>>>>>>>>>
> >>>>>>>>>> Soo.... Here's version #3! If anyone can think of how to
> >>>> keep the
> >>>>>>> three
> >>>>>>>>>> branches while addressing being forced to have a default
> >>>> branch,
> >>>>>> feel
> >>>>>>>>> free
> >>>>>>>>>> to speak up! :)
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Cordova repositories have two main branches:
> >>>>>>>>>> 1. master
> >>>>>>>>>> 2. next
> >>>>>>>>>>
> >>>>>>>>>> Topic branches exist for collaborating on features, or for
> >>>>>>> code-review
> >>>>>>>>>> purposes.
> >>>>>>>>>>
> >>>>>>>>>> Cordova uses tags to label releases.
> >>>>>>>>>> - Each release candidate has a tag. e.g. "2.2.0rc1"
> >>>>>>>>>> - Each release has a tag. e.g. "2.2.0"
> >>>>>>>>>> - The "latest" tag points to the last stable release (this
> >>>>> follows
> >>>>>>> npm
> >>>>>>>>>> conventions)
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> 1. The "next" branch.
> >>>>>>>>>> - This branch is used only when in the process of doing a
> >>>>> release.
> >>>>>>>>>> - All tags are created from this branch.
> >>>>>>>>>> - All release-candidate bug-fixes are done on this branch.
> >>>>>>>>>>
> >>>>>>>>>> 2. The "master" branch.
> >>>>>>>>>> - When not in the release-process, all commits are made here
> >>>>>>>>>> - When in the release-process, all non-bugfix commits are
> >>>> made
> >>>>>> here
> >>>>>>>>>> - This is where topic-branches are merged into.
> >>>>>>>>>>
> >>>>>>>>>> Cutting a release:
> >>>>>>>>>> 1. git checkout next && git merge --ff-only master
> >>>>>>>>>> 2. Test test test!
> >>>>>>>>>> 3. Fix bugs by committing them directly to "next" and then
> >>>> doing
> >>>>> a
> >>>>>>>> non-ff
> >>>>>>>>>> merge of next into master
> >>>>>>>>>> 4. Tag release candidate
> >>>>>>>>>> 5. Repeat steps 2-4 as necessary
> >>>>>>>>>> 6. Tag the release (both by version and by updating the
> >>>> "latest"
> >>>>>> tag)
> >>>>>>>>>> 7. Create distribution .zip file
> >>>>>>>>>> 8. Test one last time using the dist files
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Thanks,
> >>>>>>>>>>> Michael
> >>>>>>>>>>>
> >>>>>>>>>>> On Wed, Jan 23, 2013 at 11:25 AM, Brian LeRoux <b@brian.io
> >>>>>
> >>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> I'm liking it. Start in 2.5?
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Wed, Jan 23, 2013 at 1:19 PM, Filip Maj <fil@adobe.com
> >>>>>
> >>>>>> wrote:
> >>>>>>>>>>>>> Looks great Andrew!
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> If everyone's on board, how are we going to test run
> >>>> this?
> >>>>>> Flip a
> >>>>>>>>>>> switch
> >>>>>>>>>>>>> at a certain point, give it a shot with one repo for one
> >>>> RC?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On 1/22/13 12:29 PM, "Andrew Grieve" <
> >>>> agrieve@chromium.org>
> >>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Braden, you're right. I've now done some local playing
> >>>>> around
> >>>>>> in
> >>>>>>>>> git,
> >>>>>>>>>>> and
> >>>>>>>>>>>>>> have an updated proposal that uses merges instead of
> >>>>> deleting
> >>>>>>>>>> branches.
> >>>>>>>>>>>>>> PTAL:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Cordova repositories have three main branches:
> >>>>>>>>>>>>>> 1. stable
> >>>>>>>>>>>>>> 2. next
> >>>>>>>>>>>>>> 3. dev
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Topic branches also exist for collaborating on
> >>>> features, or
> >>>>>> for
> >>>>>>>>>>>>>> code-review
> >>>>>>>>>>>>>> purposes.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> There is *no* master branch, so that community-driven
> >>>> pull
> >>>>>>>> requests
> >>>>>>>>>>> will
> >>>>>>>>>>>>>> be
> >>>>>>>>>>>>>> forced to think about which branch to request against.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> 1. The "stable" branch.
> >>>>>>>>>>>>>> - Sits at the latest stable release of cordova
> >>>>>>>>>>>>>> - This changes only when doing fast-forward merges from
> >>>>> "next"
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> 2. The "next" branch.
> >>>>>>>>>>>>>> - This branch is used only when in the process of doing
> >>>> a
> >>>>>>> release.
> >>>>>>>>>>>>>> - All tags (both stable and RC) are done on this branch.
> >>>>>>>>>>>>>> - All release-candidate bug-fixes are done on this
> >>>> branch.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> 3. The "dev" branch.
> >>>>>>>>>>>>>> - This is where non-release-candidate commits are done
> >>>>>>>>>>>>>> - This is where topic-branches are merged into.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Cutting a release:
> >>>>>>>>>>>>>> 1. git checkout next && git merge --ff-only dev
> >>>>>>>>>>>>>> 2. Test test test!
> >>>>>>>>>>>>>> 3. Fix bugs by committing them directly to "next" and
> >>>> then
> >>>>>>> doing a
> >>>>>>>>>>> non-ff
> >>>>>>>>>>>>>> merge of next into dev
> >>>>>>>>>>>>>> 4. Tag release candidate
> >>>>>>>>>>>>>> 5. Repeat steps 2-4 as necessary
> >>>>>>>>>>>>>> 6. Tag the release
> >>>>>>>>>>>>>> 7. Create distribution .zip file
> >>>>>>>>>>>>>> 8. Test one last time using the dist files
> >>>>>>>>>>>>>> 9. git checkout stable && git merge --ff-only next
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Tue, Jan 22, 2013 at 1:59 PM, Braden Shepherdson
> >>>>>>>>>>>>>> <br...@chromium.org>wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I think deleting and recreating branches with the same
> >>>> name
> >>>>>> can
> >>>>>>>>> cause
> >>>>>>>>>>>>>>> badness in git[1] because of remotes. It's not really
> >>>> the
> >>>>>> same
> >>>>>>>>> branch
> >>>>>>>>>>>> in
> >>>>>>>>>>>>>>> terms of commits, and git thinks that your old stable
> >>>> and
> >>>>> the
> >>>>>>> new
> >>>>>>>>>>>> stable
> >>>>>>>>>>>>>>> differ by all of each of their commits. Tags can be
> >>>> moved
> >>>>>>>>>>> arbitrarily,
> >>>>>>>>>>>>>>> so I
> >>>>>>>>>>>>>>> think stable makes sense as a tag. I'm not sure about
> >>>> how
> >>>>>> best
> >>>>>>> to
> >>>>>>>>>>>> handle
> >>>>>>>>>>>>>>> next.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> [1]
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> http://stackoverflow.com/questions/11844581/git-delete-and-recreate-branc
> >>>>>>>>>>>>>>> h
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On Tue, Jan 22, 2013 at 11:31 AM, Andrew Grieve <
> >>>>>>>>>>> agrieve@chromium.org
> >>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Michal's attending hackathons for the week, and I'm
> >>>> not
> >>>>> sure
> >>>>>>> we
> >>>>>>>>>>> need
> >>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>> do
> >>>>>>>>>>>>>>>> a hang-out for this, as I think we really are quite
> >>>> close
> >>>>> to
> >>>>>>>>>>>> resolving
> >>>>>>>>>>>>>>>> this. I'd really like to resolve this ASAP so that we
> >>>>> don't
> >>>>>>> need
> >>>>>>>>> to
> >>>>>>>>>>>>>>> have
> >>>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>> code-freeze for this release.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Here's a proposal:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Cordova repositories have three main branches:
> >>>>>>>>>>>>>>>> 1. stable
> >>>>>>>>>>>>>>>> 2. next
> >>>>>>>>>>>>>>>> 3. dev
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Topic branches also exist for collaborating on
> >>>> features,
> >>>>> or
> >>>>>>> for
> >>>>>>>>>>>>>>> code-review
> >>>>>>>>>>>>>>>> purposes.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> There is *no* master branch, so that community-driven
> >>>> pull
> >>>>>>>>> requests
> >>>>>>>>>>>>>>> will
> >>>>>>>>>>>>>>> be
> >>>>>>>>>>>>>>>> forced to think about which branch to request against.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> 1. The "stable" branch.
> >>>>>>>>>>>>>>>> - Sits at the latest stable release of cordova
> >>>>>>>>>>>>>>>> - No one ever commits to the "stable" branch. It
> >>>> exists
> >>>>> only
> >>>>>>> as
> >>>>>>>> a
> >>>>>>>>>>>>>>>> short-cut for checking out the latest stable tag.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> 2. The "next" branch.
> >>>>>>>>>>>>>>>> - This branch exists only when in the process of
> >>>> doing a
> >>>>>>>> release.
> >>>>>>>>>>>>>>>> - All tags (both stable and RC) are done on this
> >>>> branch.
> >>>>>>>>>>>>>>>> - When a stable tag is done:
> >>>>>>>>>>>>>>>> - The existing "stable" branch is deleted
> >>>>>>>>>>>>>>>> - A new "stable" branch is created from "next".
> >>>>>>>>>>>>>>>> - The "next" branch is deleted.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> 3. The "dev" branch.
> >>>>>>>>>>>>>>>> - This is where all commits are done
> >>>>>>>>>>>>>>>> - This is where topic-branches are merged into.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Cutting a release:
> >>>>>>>>>>>>>>>> 1. Create "next" from the HEAD of "dev"
> >>>>>>>>>>>>>>>> 2. Test test test!
> >>>>>>>>>>>>>>>> 3. Fix bugs by committing them to "dev" and then
> >>>>>>> cherry-picking
> >>>>>>>>>>> them
> >>>>>>>>>>>>>>> into
> >>>>>>>>>>>>>>>> "next"
> >>>>>>>>>>>>>>>> 4. Tag release candidate
> >>>>>>>>>>>>>>>> 5. Repeat steps 2-4 as necessary
> >>>>>>>>>>>>>>>> 6. Tag the release
> >>>>>>>>>>>>>>>> 7. Create distribution .zip file
> >>>>>>>>>>>>>>>> 8. Test one last time using the dist files
> >>>>>>>>>>>>>>>> 9. Delete "stable"
> >>>>>>>>>>>>>>>> 10. Create a new "stable" by branching from the HEAD
> >>>> of
> >>>>>> "next"
> >>>>>>>>>>>>>>>> 11. Delete the "next" branch
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On Wed, Jan 16, 2013 at 10:34 AM, Michal Mocny <
> >>>>>>>>>>> mmocny@chromium.org>
> >>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Just going to throw out one of my personal
> >>>> requirements
> >>>>> for
> >>>>>>>>>>>> whatever
> >>>>>>>>>>>>>>>>> proposal we come up with, so it doesn't get lost:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> * Feature branches are great for feature work and/or
> >>>>> large
> >>>>>>>>>>> sweeping
> >>>>>>>>>>>>>>>>> changes, as are JIRA bugs for tracking them, but
> >>>> cordova
> >>>>>> has
> >>>>>>>> many
> >>>>>>>>>>>>>>> many
> >>>>>>>>>>>>>>>>> trivial issues that could be fixed with "drive-by"
> >>>>> patches
> >>>>>>> that
> >>>>>>>>>>>>>>> require
> >>>>>>>>>>>>>>>> as
> >>>>>>>>>>>>>>>>> little friction to commit as possible.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On Tue, Jan 15, 2013 at 3:05 PM, Marcel Kinard <
> >>>>>>>>>>> cmarcelk@gmail.com
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> How about if there is a specific straw man proposal
> >>>> at
> >>>>> the
> >>>>>>>>>>>>>>> beginning
> >>>>>>>>>>>>>>> of
> >>>>>>>>>>>>>>>>>> the face-time? Then the folks that are in agreement
> >>>>> won't
> >>>>>>> need
> >>>>>>>>>>> to
> >>>>>>>>>>>>>>> say
> >>>>>>>>>>>>>>>>>> anything ;-)
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Seriously, making adjustments to something tangible
> >>>> is
> >>>>>>> easier
> >>>>>>>>>>>> than
> >>>>>>>>>>>>>>>>>> instantiating it from scratch. A volunteer for a
> >>>> very
> >>>>>> simple
> >>>>>>>>>>>>>>> writeup
> >>>>>>>>>>>>>>> on
> >>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>> wiki?
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> -- Marcel Kinard
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On 1/14/2013 10:06 PM, Michal Mocny wrote:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Okay gentlemen, I think there have been countless
> >>>> good
> >>>>>>> points
> >>>>>>>>>>>>>>> made
> >>>>>>>>>>>>>>>> from
> >>>>>>>>>>>>>>>>>>> all
> >>>>>>>>>>>>>>>>>>> parties, but also some bike-shedding.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Perhaps it is time to schedule some face-time to
> >>>> better
> >>>>>>>>>>>>>>> articulate
> >>>>>>>>>>>>>>>> some
> >>>>>>>>>>>>>>>>> of
> >>>>>>>>>>>>>>>>>>> the finer points, and to help come to some
> >>>> consensus?
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> -Michal
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> @purplecabbage
> >>>>>>>> risingj.com
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> @purplecabbage
> >>>>> risingj.com
> >>>>>
> >>>>
> >>>
> >>>
> >>
> >
> >
> > --
> > @purplecabbage
> > risingj.com
>
>
Re: too long to package a release?
Posted by Marcel Kinard <cm...@gmail.com>.
With 2.5 starting, it appears time to poke this thread.
- Is the Google doc refreshed with the latest consensus?
- If so, should the Google doc be transferred to a wiki page?
- Have the necessary branches been created?
- Are we all in the boat, and understand how to row this beast?
-- Marcel Kinard
On Jan 24, 2013, at 5:14 PM, Jesse <pu...@gmail.com> wrote:
> Nice Shaz, but I was hoping it was a github style network visualization
> that included a few versions worth of merges.
> Who wants to draw that?
>
> On Thu, Jan 24, 2013 at 2:05 PM, Shazron <sh...@gmail.com> wrote:
>
>> Inline image got mangled, here it is linked: http://cl.ly/MOrD
>>
>>
>> On Thu, Jan 24, 2013 at 1:39 PM, Shazron <sh...@gmail.com> wrote:
>>
>>> Thanks for the pseudocode Andrew, seems simpler to understand ;) Jesse's
>>> re-factor makes it even easier. Here's my contrib for those more visually
>>> inclined:
>>>
>>>
>>> [image: Inline image 2]
>>>
>>>
>>> On Thu, Jan 24, 2013 at 1:29 PM, Andrew Grieve <ag...@chromium.org>wrote:
>>>
>>>> Nice! even simpler. :)
>>>>
>>>>
>>>> On Thu, Jan 24, 2013 at 3:44 PM, Jesse <pu...@gmail.com> wrote:
>>>>
>>>>> Thanks for clarifying Andrew. et al, I guess I was mis-understanding
>>>> some
>>>>> of the earlier discussion around naming stuff.
>>>>>
>>>>> So everything is going to master all the time, and we only care about
>>>>> 'next' if we are inReleaseMode and it is a bug fix?
>>>>>
>>>>> if(inReleaseMode && isBugFix) {
>>>>> commitToBranch('next');
>>>>> mergeBranch('next').into('master');
>>>>> }
>>>>> else {
>>>>> commitToBranch('master');
>>>>> }
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Jan 24, 2013 at 12:29 PM, Andrew Grieve <agrieve@chromium.org
>>>>>> wrote:
>>>>>
>>>>>> Just to clarify - there should be *no* using of the git
>>>> cherry-picking
>>>>>> command, only git merge.
>>>>>>
>>>>>> Jesse - not sure what you're referring to with "branch must be named
>>>> x".
>>>>>> The latest revision of the proposal has only two branches: master and
>>>>> next.
>>>>>> Do you mean you don't like the name "next"?
>>>>>>
>>>>>> Maybe the proposal will seem simpler if put in the form of code :)
>>>>>>
>>>>>> if (!inReleaseMode) {
>>>>>> commitToBranch('master');
>>>>>> } else {
>>>>>> if (isBugFix) {
>>>>>> commitToBranch('next');
>>>>>> mergeBranch('next').into('master');
>>>>>> } else {
>>>>>> commitToBranch('master');
>>>>>> }
>>>>>> }
>>>>>>
>>>>>>
>>>>>> On Thu, Jan 24, 2013 at 3:06 PM, Braden Shepherdson <
>>>> braden@chromium.org
>>>>>>> wrote:
>>>>>>
>>>>>>> Most of the time the flow will be unchanged: push to master.
>>>> Tagging
>>>>>> things
>>>>>>> we already know how to do; that doesn't change.
>>>>>>>
>>>>>>> The only new flow for most people is cherrypicking bug fixes from
>>>>> master
>>>>>> to
>>>>>>> next, which we can give examples of. Plus that could remain the
>>>>>>> responsibility of the main platform maintainers, who are doing the
>>>>>> tagging.
>>>>>>>
>>>>>>> Braden
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Jan 24, 2013 at 2:56 PM, Jesse <pu...@gmail.com>
>>>>> wrote:
>>>>>>>
>>>>>>>> On Thu, Jan 24, 2013 at 11:09 AM, Braden Shepherdson <
>>>>>>> braden@chromium.org
>>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> The founding goal we're trying to accomplish here is that we
>>>> don't
>>>>>> want
>>>>>>>>> everyone sitting on changes to be in the next version while we
>>>> use
>>>>>>> master
>>>>>>>>> to prep a release.
>>>>>>>>>
>>>>>>>>> I don't think having one branch for prepping the release and
>>>>> another
>>>>>>> for
>>>>>>>>> main development is a lot of bureaucracy.
>>>>>>>>>
>>>>>>>>
>>>>>>>> It is not, the 'branch must be named x' is mainly where I have
>>>>>> concerns.
>>>>>>>> Really I just want things simple.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Jan 24, 2013 at 1:57 PM, Jesse MacFadyen <
>>>>>>>> purplecabbage@gmail.com
>>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> I have been quietly listening on this thread, but thought I
>>>>> should
>>>>>> at
>>>>>>>>>> least share my opinion.
>>>>>>>>>>
>>>>>>>>>> I don't think adding contribution rules helps anyone. Git is
>>>>>>>>>> complicated enough as it is, and this just all seems like
>>>>>>> bureaucracy.
>>>>>>>>>>
>>>>>>>>>> I think master should always contain the latest stable code,
>>>> and
>>>>> be
>>>>>>>>>> periodically tagged with rc's and versions.
>>>>>>>>>> All work should be done in personal forks and feature
>>>> branches.
>>>>>>>>>> If the latest tag of master is an rc, then we should only be
>>>>>> merging
>>>>>>>>>> bugfixes, until the release.
>>>>>>>>>> Immediately after tagging a version we decide which feature
>>>>>> branches
>>>>>>>>>> and pull requests to pull in, and go for it.
>>>>>>>>>>
>>>>>>>>>> I don't think this is much different from what we have, but I
>>>>> think
>>>>>>>>>> that is good.
>>>>>>>>>> The suggestions thus far, while interesting, don't increase
>>>> our
>>>>>>>>>> velocity in my opinion. Also, I can also pretty much guaranty
>>>>> I'll
>>>>>>>>>> screw it up for the next 3-4 versions. ( because I'm dumb )
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Jesse
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 2013-01-24, at 5:53 AM, Andrew Grieve <
>>>> agrieve@chromium.org>
>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> On Wed, Jan 23, 2013 at 4:58 PM, Michael Brooks <
>>>>>>>>> michael@michaelbrooks.ca
>>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Before we move forward, I have a few questions about the
>>>> "no
>>>>>>> master"
>>>>>>>>>>> approach.
>>>>>>>>>>>
>>>>>>>>>>> There is *no* master branch, so that community-driven pull
>>>>>> requests
>>>>>>>>> will
>>>>>>>>>> be
>>>>>>>>>>>> forced to think about which branch to request against.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> - Andrew, can you cite other projects that do not use a
>>>> master
>>>>>>>> branch?
>>>>>>>>>> This project is my first time using git / github, so I don't
>>>> have
>>>>>>> much
>>>>>>>> to
>>>>>>>>>> draw from. I was going off of others' suggestions on this
>>>> thread
>>>>>>> when I
>>>>>>>>>> proposed the names.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> - On Github, you must have a default branch. If not
>>>> master, it
>>>>>> must
>>>>>>>> be
>>>>>>>>>>> something else. So, users are not forced to think about the
>>>>>> branch
>>>>>>> to
>>>>>>>>>> send
>>>>>>>>>>> a pull request again... they will likely just use the
>>>> default.
>>>>>>>>>>
>>>>>>>>>> Hmm, good point. The goal is to get people downloading
>>>> Cordova
>>>>> for
>>>>>>> use
>>>>>>>> to
>>>>>>>>>> end up with Stable, and for developers to send pull requests
>>>>>> against
>>>>>>>> dev.
>>>>>>>>>> With a forced default branch, I don't think we can accomplish
>>>>> this.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> - Why is the "stable" branch not just "master"?
>>>>>>>>>>
>>>>>>>>>> My thinking was that it's not obvious whether Master ==
>>>> bleeding
>>>>>>> edge,
>>>>>>>> or
>>>>>>>>>> Master == Stable version. Using the names "dev" and "stable"
>>>>> makes
>>>>>>> it a
>>>>>>>>> bit
>>>>>>>>>> clear.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> So... If github forces us to have a default branch, I'm
>>>> thinking
>>>>>> that
>>>>>>>>>> having users send pull requests against "dev" is more
>>>> valuable
>>>>> than
>>>>>>>>> having
>>>>>>>>>> people download the latest "stable" by default. If people are
>>>>>> pulling
>>>>>>>>> code
>>>>>>>>>> from github rather than from our release .zip files, then
>>>> it's
>>>>>> likely
>>>>>>>>> they
>>>>>>>>>> want to hack on it anyways, or that they want the dev
>>>> version to
>>>>>> see
>>>>>>> if
>>>>>>>>>> bugs are fixed.
>>>>>>>>>>
>>>>>>>>>> Soo.... Here's version #3! If anyone can think of how to
>>>> keep the
>>>>>>> three
>>>>>>>>>> branches while addressing being forced to have a default
>>>> branch,
>>>>>> feel
>>>>>>>>> free
>>>>>>>>>> to speak up! :)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Cordova repositories have two main branches:
>>>>>>>>>> 1. master
>>>>>>>>>> 2. next
>>>>>>>>>>
>>>>>>>>>> Topic branches exist for collaborating on features, or for
>>>>>>> code-review
>>>>>>>>>> purposes.
>>>>>>>>>>
>>>>>>>>>> Cordova uses tags to label releases.
>>>>>>>>>> - Each release candidate has a tag. e.g. "2.2.0rc1"
>>>>>>>>>> - Each release has a tag. e.g. "2.2.0"
>>>>>>>>>> - The "latest" tag points to the last stable release (this
>>>>> follows
>>>>>>> npm
>>>>>>>>>> conventions)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 1. The "next" branch.
>>>>>>>>>> - This branch is used only when in the process of doing a
>>>>> release.
>>>>>>>>>> - All tags are created from this branch.
>>>>>>>>>> - All release-candidate bug-fixes are done on this branch.
>>>>>>>>>>
>>>>>>>>>> 2. The "master" branch.
>>>>>>>>>> - When not in the release-process, all commits are made here
>>>>>>>>>> - When in the release-process, all non-bugfix commits are
>>>> made
>>>>>> here
>>>>>>>>>> - This is where topic-branches are merged into.
>>>>>>>>>>
>>>>>>>>>> Cutting a release:
>>>>>>>>>> 1. git checkout next && git merge --ff-only master
>>>>>>>>>> 2. Test test test!
>>>>>>>>>> 3. Fix bugs by committing them directly to "next" and then
>>>> doing
>>>>> a
>>>>>>>> non-ff
>>>>>>>>>> merge of next into master
>>>>>>>>>> 4. Tag release candidate
>>>>>>>>>> 5. Repeat steps 2-4 as necessary
>>>>>>>>>> 6. Tag the release (both by version and by updating the
>>>> "latest"
>>>>>> tag)
>>>>>>>>>> 7. Create distribution .zip file
>>>>>>>>>> 8. Test one last time using the dist files
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Michael
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Jan 23, 2013 at 11:25 AM, Brian LeRoux <b@brian.io
>>>>>
>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> I'm liking it. Start in 2.5?
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, Jan 23, 2013 at 1:19 PM, Filip Maj <fil@adobe.com
>>>>>
>>>>>> wrote:
>>>>>>>>>>>>> Looks great Andrew!
>>>>>>>>>>>>>
>>>>>>>>>>>>> If everyone's on board, how are we going to test run
>>>> this?
>>>>>> Flip a
>>>>>>>>>>> switch
>>>>>>>>>>>>> at a certain point, give it a shot with one repo for one
>>>> RC?
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 1/22/13 12:29 PM, "Andrew Grieve" <
>>>> agrieve@chromium.org>
>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Braden, you're right. I've now done some local playing
>>>>> around
>>>>>> in
>>>>>>>>> git,
>>>>>>>>>>> and
>>>>>>>>>>>>>> have an updated proposal that uses merges instead of
>>>>> deleting
>>>>>>>>>> branches.
>>>>>>>>>>>>>> PTAL:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Cordova repositories have three main branches:
>>>>>>>>>>>>>> 1. stable
>>>>>>>>>>>>>> 2. next
>>>>>>>>>>>>>> 3. dev
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Topic branches also exist for collaborating on
>>>> features, or
>>>>>> for
>>>>>>>>>>>>>> code-review
>>>>>>>>>>>>>> purposes.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> There is *no* master branch, so that community-driven
>>>> pull
>>>>>>>> requests
>>>>>>>>>>> will
>>>>>>>>>>>>>> be
>>>>>>>>>>>>>> forced to think about which branch to request against.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 1. The "stable" branch.
>>>>>>>>>>>>>> - Sits at the latest stable release of cordova
>>>>>>>>>>>>>> - This changes only when doing fast-forward merges from
>>>>> "next"
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2. The "next" branch.
>>>>>>>>>>>>>> - This branch is used only when in the process of doing
>>>> a
>>>>>>> release.
>>>>>>>>>>>>>> - All tags (both stable and RC) are done on this branch.
>>>>>>>>>>>>>> - All release-candidate bug-fixes are done on this
>>>> branch.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 3. The "dev" branch.
>>>>>>>>>>>>>> - This is where non-release-candidate commits are done
>>>>>>>>>>>>>> - This is where topic-branches are merged into.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Cutting a release:
>>>>>>>>>>>>>> 1. git checkout next && git merge --ff-only dev
>>>>>>>>>>>>>> 2. Test test test!
>>>>>>>>>>>>>> 3. Fix bugs by committing them directly to "next" and
>>>> then
>>>>>>> doing a
>>>>>>>>>>> non-ff
>>>>>>>>>>>>>> merge of next into dev
>>>>>>>>>>>>>> 4. Tag release candidate
>>>>>>>>>>>>>> 5. Repeat steps 2-4 as necessary
>>>>>>>>>>>>>> 6. Tag the release
>>>>>>>>>>>>>> 7. Create distribution .zip file
>>>>>>>>>>>>>> 8. Test one last time using the dist files
>>>>>>>>>>>>>> 9. git checkout stable && git merge --ff-only next
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Tue, Jan 22, 2013 at 1:59 PM, Braden Shepherdson
>>>>>>>>>>>>>> <br...@chromium.org>wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I think deleting and recreating branches with the same
>>>> name
>>>>>> can
>>>>>>>>> cause
>>>>>>>>>>>>>>> badness in git[1] because of remotes. It's not really
>>>> the
>>>>>> same
>>>>>>>>> branch
>>>>>>>>>>>> in
>>>>>>>>>>>>>>> terms of commits, and git thinks that your old stable
>>>> and
>>>>> the
>>>>>>> new
>>>>>>>>>>>> stable
>>>>>>>>>>>>>>> differ by all of each of their commits. Tags can be
>>>> moved
>>>>>>>>>>> arbitrarily,
>>>>>>>>>>>>>>> so I
>>>>>>>>>>>>>>> think stable makes sense as a tag. I'm not sure about
>>>> how
>>>>>> best
>>>>>>> to
>>>>>>>>>>>> handle
>>>>>>>>>>>>>>> next.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> [1]
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>> http://stackoverflow.com/questions/11844581/git-delete-and-recreate-branc
>>>>>>>>>>>>>>> h
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Tue, Jan 22, 2013 at 11:31 AM, Andrew Grieve <
>>>>>>>>>>> agrieve@chromium.org
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Michal's attending hackathons for the week, and I'm
>>>> not
>>>>> sure
>>>>>>> we
>>>>>>>>>>> need
>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>> do
>>>>>>>>>>>>>>>> a hang-out for this, as I think we really are quite
>>>> close
>>>>> to
>>>>>>>>>>>> resolving
>>>>>>>>>>>>>>>> this. I'd really like to resolve this ASAP so that we
>>>>> don't
>>>>>>> need
>>>>>>>>> to
>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>> code-freeze for this release.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Here's a proposal:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Cordova repositories have three main branches:
>>>>>>>>>>>>>>>> 1. stable
>>>>>>>>>>>>>>>> 2. next
>>>>>>>>>>>>>>>> 3. dev
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Topic branches also exist for collaborating on
>>>> features,
>>>>> or
>>>>>>> for
>>>>>>>>>>>>>>> code-review
>>>>>>>>>>>>>>>> purposes.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> There is *no* master branch, so that community-driven
>>>> pull
>>>>>>>>> requests
>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>> forced to think about which branch to request against.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 1. The "stable" branch.
>>>>>>>>>>>>>>>> - Sits at the latest stable release of cordova
>>>>>>>>>>>>>>>> - No one ever commits to the "stable" branch. It
>>>> exists
>>>>> only
>>>>>>> as
>>>>>>>> a
>>>>>>>>>>>>>>>> short-cut for checking out the latest stable tag.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 2. The "next" branch.
>>>>>>>>>>>>>>>> - This branch exists only when in the process of
>>>> doing a
>>>>>>>> release.
>>>>>>>>>>>>>>>> - All tags (both stable and RC) are done on this
>>>> branch.
>>>>>>>>>>>>>>>> - When a stable tag is done:
>>>>>>>>>>>>>>>> - The existing "stable" branch is deleted
>>>>>>>>>>>>>>>> - A new "stable" branch is created from "next".
>>>>>>>>>>>>>>>> - The "next" branch is deleted.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 3. The "dev" branch.
>>>>>>>>>>>>>>>> - This is where all commits are done
>>>>>>>>>>>>>>>> - This is where topic-branches are merged into.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Cutting a release:
>>>>>>>>>>>>>>>> 1. Create "next" from the HEAD of "dev"
>>>>>>>>>>>>>>>> 2. Test test test!
>>>>>>>>>>>>>>>> 3. Fix bugs by committing them to "dev" and then
>>>>>>> cherry-picking
>>>>>>>>>>> them
>>>>>>>>>>>>>>> into
>>>>>>>>>>>>>>>> "next"
>>>>>>>>>>>>>>>> 4. Tag release candidate
>>>>>>>>>>>>>>>> 5. Repeat steps 2-4 as necessary
>>>>>>>>>>>>>>>> 6. Tag the release
>>>>>>>>>>>>>>>> 7. Create distribution .zip file
>>>>>>>>>>>>>>>> 8. Test one last time using the dist files
>>>>>>>>>>>>>>>> 9. Delete "stable"
>>>>>>>>>>>>>>>> 10. Create a new "stable" by branching from the HEAD
>>>> of
>>>>>> "next"
>>>>>>>>>>>>>>>> 11. Delete the "next" branch
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Wed, Jan 16, 2013 at 10:34 AM, Michal Mocny <
>>>>>>>>>>> mmocny@chromium.org>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Just going to throw out one of my personal
>>>> requirements
>>>>> for
>>>>>>>>>>>> whatever
>>>>>>>>>>>>>>>>> proposal we come up with, so it doesn't get lost:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> * Feature branches are great for feature work and/or
>>>>> large
>>>>>>>>>>> sweeping
>>>>>>>>>>>>>>>>> changes, as are JIRA bugs for tracking them, but
>>>> cordova
>>>>>> has
>>>>>>>> many
>>>>>>>>>>>>>>> many
>>>>>>>>>>>>>>>>> trivial issues that could be fixed with "drive-by"
>>>>> patches
>>>>>>> that
>>>>>>>>>>>>>>> require
>>>>>>>>>>>>>>>> as
>>>>>>>>>>>>>>>>> little friction to commit as possible.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Tue, Jan 15, 2013 at 3:05 PM, Marcel Kinard <
>>>>>>>>>>> cmarcelk@gmail.com
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> How about if there is a specific straw man proposal
>>>> at
>>>>> the
>>>>>>>>>>>>>>> beginning
>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>> the face-time? Then the folks that are in agreement
>>>>> won't
>>>>>>> need
>>>>>>>>>>> to
>>>>>>>>>>>>>>> say
>>>>>>>>>>>>>>>>>> anything ;-)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Seriously, making adjustments to something tangible
>>>> is
>>>>>>> easier
>>>>>>>>>>>> than
>>>>>>>>>>>>>>>>>> instantiating it from scratch. A volunteer for a
>>>> very
>>>>>> simple
>>>>>>>>>>>>>>> writeup
>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> wiki?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> -- Marcel Kinard
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 1/14/2013 10:06 PM, Michal Mocny wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Okay gentlemen, I think there have been countless
>>>> good
>>>>>>> points
>>>>>>>>>>>>>>> made
>>>>>>>>>>>>>>>> from
>>>>>>>>>>>>>>>>>>> all
>>>>>>>>>>>>>>>>>>> parties, but also some bike-shedding.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Perhaps it is time to schedule some face-time to
>>>> better
>>>>>>>>>>>>>>> articulate
>>>>>>>>>>>>>>>> some
>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>>> the finer points, and to help come to some
>>>> consensus?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> -Michal
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> @purplecabbage
>>>>>>>> risingj.com
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> @purplecabbage
>>>>> risingj.com
>>>>>
>>>>
>>>
>>>
>>
>
>
> --
> @purplecabbage
> risingj.com
Re: too long to package a release?
Posted by Jesse <pu...@gmail.com>.
Nice Shaz, but I was hoping it was a github style network visualization
that included a few versions worth of merges.
Who wants to draw that?
On Thu, Jan 24, 2013 at 2:05 PM, Shazron <sh...@gmail.com> wrote:
> Inline image got mangled, here it is linked: http://cl.ly/MOrD
>
>
> On Thu, Jan 24, 2013 at 1:39 PM, Shazron <sh...@gmail.com> wrote:
>
>> Thanks for the pseudocode Andrew, seems simpler to understand ;) Jesse's
>> re-factor makes it even easier. Here's my contrib for those more visually
>> inclined:
>>
>>
>> [image: Inline image 2]
>>
>>
>> On Thu, Jan 24, 2013 at 1:29 PM, Andrew Grieve <ag...@chromium.org>wrote:
>>
>>> Nice! even simpler. :)
>>>
>>>
>>> On Thu, Jan 24, 2013 at 3:44 PM, Jesse <pu...@gmail.com> wrote:
>>>
>>> > Thanks for clarifying Andrew. et al, I guess I was mis-understanding
>>> some
>>> > of the earlier discussion around naming stuff.
>>> >
>>> > So everything is going to master all the time, and we only care about
>>> > 'next' if we are inReleaseMode and it is a bug fix?
>>> >
>>> > if(inReleaseMode && isBugFix) {
>>> > commitToBranch('next');
>>> > mergeBranch('next').into('master');
>>> > }
>>> > else {
>>> > commitToBranch('master');
>>> > }
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > On Thu, Jan 24, 2013 at 12:29 PM, Andrew Grieve <agrieve@chromium.org
>>> > >wrote:
>>> >
>>> > > Just to clarify - there should be *no* using of the git
>>> cherry-picking
>>> > > command, only git merge.
>>> > >
>>> > > Jesse - not sure what you're referring to with "branch must be named
>>> x".
>>> > > The latest revision of the proposal has only two branches: master and
>>> > next.
>>> > > Do you mean you don't like the name "next"?
>>> > >
>>> > > Maybe the proposal will seem simpler if put in the form of code :)
>>> > >
>>> > > if (!inReleaseMode) {
>>> > > commitToBranch('master');
>>> > > } else {
>>> > > if (isBugFix) {
>>> > > commitToBranch('next');
>>> > > mergeBranch('next').into('master');
>>> > > } else {
>>> > > commitToBranch('master');
>>> > > }
>>> > > }
>>> > >
>>> > >
>>> > > On Thu, Jan 24, 2013 at 3:06 PM, Braden Shepherdson <
>>> braden@chromium.org
>>> > > >wrote:
>>> > >
>>> > > > Most of the time the flow will be unchanged: push to master.
>>> Tagging
>>> > > things
>>> > > > we already know how to do; that doesn't change.
>>> > > >
>>> > > > The only new flow for most people is cherrypicking bug fixes from
>>> > master
>>> > > to
>>> > > > next, which we can give examples of. Plus that could remain the
>>> > > > responsibility of the main platform maintainers, who are doing the
>>> > > tagging.
>>> > > >
>>> > > > Braden
>>> > > >
>>> > > >
>>> > > > On Thu, Jan 24, 2013 at 2:56 PM, Jesse <pu...@gmail.com>
>>> > wrote:
>>> > > >
>>> > > > > On Thu, Jan 24, 2013 at 11:09 AM, Braden Shepherdson <
>>> > > > braden@chromium.org
>>> > > > > >wrote:
>>> > > > >
>>> > > > > > The founding goal we're trying to accomplish here is that we
>>> don't
>>> > > want
>>> > > > > > everyone sitting on changes to be in the next version while we
>>> use
>>> > > > master
>>> > > > > > to prep a release.
>>> > > > > >
>>> > > > > > I don't think having one branch for prepping the release and
>>> > another
>>> > > > for
>>> > > > > > main development is a lot of bureaucracy.
>>> > > > > >
>>> > > > >
>>> > > > > It is not, the 'branch must be named x' is mainly where I have
>>> > > concerns.
>>> > > > > Really I just want things simple.
>>> > > > >
>>> > > > >
>>> > > > > >
>>> > > > > >
>>> > > > > > On Thu, Jan 24, 2013 at 1:57 PM, Jesse MacFadyen <
>>> > > > > purplecabbage@gmail.com
>>> > > > > > >wrote:
>>> > > > > >
>>> > > > > > > I have been quietly listening on this thread, but thought I
>>> > should
>>> > > at
>>> > > > > > > least share my opinion.
>>> > > > > > >
>>> > > > > > > I don't think adding contribution rules helps anyone. Git is
>>> > > > > > > complicated enough as it is, and this just all seems like
>>> > > > bureaucracy.
>>> > > > > > >
>>> > > > > > > I think master should always contain the latest stable code,
>>> and
>>> > be
>>> > > > > > > periodically tagged with rc's and versions.
>>> > > > > > > All work should be done in personal forks and feature
>>> branches.
>>> > > > > > > If the latest tag of master is an rc, then we should only be
>>> > > merging
>>> > > > > > > bugfixes, until the release.
>>> > > > > > > Immediately after tagging a version we decide which feature
>>> > > branches
>>> > > > > > > and pull requests to pull in, and go for it.
>>> > > > > > >
>>> > > > > > > I don't think this is much different from what we have, but I
>>> > think
>>> > > > > > > that is good.
>>> > > > > > > The suggestions thus far, while interesting, don't increase
>>> our
>>> > > > > > > velocity in my opinion. Also, I can also pretty much guaranty
>>> > I'll
>>> > > > > > > screw it up for the next 3-4 versions. ( because I'm dumb )
>>> > > > > > >
>>> > > > > > > Cheers,
>>> > > > > > > Jesse
>>> > > > > > >
>>> > > > > > >
>>> > > > > > >
>>> > > > > > > On 2013-01-24, at 5:53 AM, Andrew Grieve <
>>> agrieve@chromium.org>
>>> > > > wrote:
>>> > > > > > >
>>> > > > > > > On Wed, Jan 23, 2013 at 4:58 PM, Michael Brooks <
>>> > > > > > michael@michaelbrooks.ca
>>> > > > > > > >wrote:
>>> > > > > > >
>>> > > > > > > > Before we move forward, I have a few questions about the
>>> "no
>>> > > > master"
>>> > > > > > > > approach.
>>> > > > > > > >
>>> > > > > > > > There is *no* master branch, so that community-driven pull
>>> > > requests
>>> > > > > > will
>>> > > > > > > be
>>> > > > > > > >> forced to think about which branch to request against.
>>> > > > > > > >
>>> > > > > > > >
>>> > > > > > > > - Andrew, can you cite other projects that do not use a
>>> master
>>> > > > > branch?
>>> > > > > > > This project is my first time using git / github, so I don't
>>> have
>>> > > > much
>>> > > > > to
>>> > > > > > > draw from. I was going off of others' suggestions on this
>>> thread
>>> > > > when I
>>> > > > > > > proposed the names.
>>> > > > > > >
>>> > > > > > >
>>> > > > > > > > - On Github, you must have a default branch. If not
>>> master, it
>>> > > must
>>> > > > > be
>>> > > > > > > > something else. So, users are not forced to think about the
>>> > > branch
>>> > > > to
>>> > > > > > > send
>>> > > > > > > > a pull request again... they will likely just use the
>>> default.
>>> > > > > > >
>>> > > > > > > Hmm, good point. The goal is to get people downloading
>>> Cordova
>>> > for
>>> > > > use
>>> > > > > to
>>> > > > > > > end up with Stable, and for developers to send pull requests
>>> > > against
>>> > > > > dev.
>>> > > > > > > With a forced default branch, I don't think we can accomplish
>>> > this.
>>> > > > > > >
>>> > > > > > >
>>> > > > > > > >
>>> > > > > > > > - Why is the "stable" branch not just "master"?
>>> > > > > > >
>>> > > > > > > My thinking was that it's not obvious whether Master ==
>>> bleeding
>>> > > > edge,
>>> > > > > or
>>> > > > > > > Master == Stable version. Using the names "dev" and "stable"
>>> > makes
>>> > > > it a
>>> > > > > > bit
>>> > > > > > > clear.
>>> > > > > > >
>>> > > > > > >
>>> > > > > > >
>>> > > > > > > So... If github forces us to have a default branch, I'm
>>> thinking
>>> > > that
>>> > > > > > > having users send pull requests against "dev" is more
>>> valuable
>>> > than
>>> > > > > > having
>>> > > > > > > people download the latest "stable" by default. If people are
>>> > > pulling
>>> > > > > > code
>>> > > > > > > from github rather than from our release .zip files, then
>>> it's
>>> > > likely
>>> > > > > > they
>>> > > > > > > want to hack on it anyways, or that they want the dev
>>> version to
>>> > > see
>>> > > > if
>>> > > > > > > bugs are fixed.
>>> > > > > > >
>>> > > > > > > Soo.... Here's version #3! If anyone can think of how to
>>> keep the
>>> > > > three
>>> > > > > > > branches while addressing being forced to have a default
>>> branch,
>>> > > feel
>>> > > > > > free
>>> > > > > > > to speak up! :)
>>> > > > > > >
>>> > > > > > >
>>> > > > > > > Cordova repositories have two main branches:
>>> > > > > > > 1. master
>>> > > > > > > 2. next
>>> > > > > > >
>>> > > > > > > Topic branches exist for collaborating on features, or for
>>> > > > code-review
>>> > > > > > > purposes.
>>> > > > > > >
>>> > > > > > > Cordova uses tags to label releases.
>>> > > > > > > - Each release candidate has a tag. e.g. "2.2.0rc1"
>>> > > > > > > - Each release has a tag. e.g. "2.2.0"
>>> > > > > > > - The "latest" tag points to the last stable release (this
>>> > follows
>>> > > > npm
>>> > > > > > > conventions)
>>> > > > > > >
>>> > > > > > >
>>> > > > > > > 1. The "next" branch.
>>> > > > > > > - This branch is used only when in the process of doing a
>>> > release.
>>> > > > > > > - All tags are created from this branch.
>>> > > > > > > - All release-candidate bug-fixes are done on this branch.
>>> > > > > > >
>>> > > > > > > 2. The "master" branch.
>>> > > > > > > - When not in the release-process, all commits are made here
>>> > > > > > > - When in the release-process, all non-bugfix commits are
>>> made
>>> > > here
>>> > > > > > > - This is where topic-branches are merged into.
>>> > > > > > >
>>> > > > > > > Cutting a release:
>>> > > > > > > 1. git checkout next && git merge --ff-only master
>>> > > > > > > 2. Test test test!
>>> > > > > > > 3. Fix bugs by committing them directly to "next" and then
>>> doing
>>> > a
>>> > > > > non-ff
>>> > > > > > > merge of next into master
>>> > > > > > > 4. Tag release candidate
>>> > > > > > > 5. Repeat steps 2-4 as necessary
>>> > > > > > > 6. Tag the release (both by version and by updating the
>>> "latest"
>>> > > tag)
>>> > > > > > > 7. Create distribution .zip file
>>> > > > > > > 8. Test one last time using the dist files
>>> > > > > > >
>>> > > > > > >
>>> > > > > > >
>>> > > > > > >
>>> > > > > > >
>>> > > > > > >
>>> > > > > > >
>>> > > > > > > >
>>> > > > > > > > Thanks,
>>> > > > > > > > Michael
>>> > > > > > > >
>>> > > > > > > > On Wed, Jan 23, 2013 at 11:25 AM, Brian LeRoux <b@brian.io
>>> >
>>> > > wrote:
>>> > > > > > > >
>>> > > > > > > >> I'm liking it. Start in 2.5?
>>> > > > > > > >>
>>> > > > > > > >> On Wed, Jan 23, 2013 at 1:19 PM, Filip Maj <fil@adobe.com
>>> >
>>> > > wrote:
>>> > > > > > > >>> Looks great Andrew!
>>> > > > > > > >>>
>>> > > > > > > >>> If everyone's on board, how are we going to test run
>>> this?
>>> > > Flip a
>>> > > > > > > > switch
>>> > > > > > > >>> at a certain point, give it a shot with one repo for one
>>> RC?
>>> > > > > > > >>>
>>> > > > > > > >>> On 1/22/13 12:29 PM, "Andrew Grieve" <
>>> agrieve@chromium.org>
>>> > > > wrote:
>>> > > > > > > >>>
>>> > > > > > > >>>> Braden, you're right. I've now done some local playing
>>> > around
>>> > > in
>>> > > > > > git,
>>> > > > > > > > and
>>> > > > > > > >>>> have an updated proposal that uses merges instead of
>>> > deleting
>>> > > > > > > branches.
>>> > > > > > > >>>> PTAL:
>>> > > > > > > >>>>
>>> > > > > > > >>>> Cordova repositories have three main branches:
>>> > > > > > > >>>> 1. stable
>>> > > > > > > >>>> 2. next
>>> > > > > > > >>>> 3. dev
>>> > > > > > > >>>>
>>> > > > > > > >>>> Topic branches also exist for collaborating on
>>> features, or
>>> > > for
>>> > > > > > > >>>> code-review
>>> > > > > > > >>>> purposes.
>>> > > > > > > >>>>
>>> > > > > > > >>>> There is *no* master branch, so that community-driven
>>> pull
>>> > > > > requests
>>> > > > > > > > will
>>> > > > > > > >>>> be
>>> > > > > > > >>>> forced to think about which branch to request against.
>>> > > > > > > >>>>
>>> > > > > > > >>>> 1. The "stable" branch.
>>> > > > > > > >>>> - Sits at the latest stable release of cordova
>>> > > > > > > >>>> - This changes only when doing fast-forward merges from
>>> > "next"
>>> > > > > > > >>>>
>>> > > > > > > >>>> 2. The "next" branch.
>>> > > > > > > >>>> - This branch is used only when in the process of doing
>>> a
>>> > > > release.
>>> > > > > > > >>>> - All tags (both stable and RC) are done on this branch.
>>> > > > > > > >>>> - All release-candidate bug-fixes are done on this
>>> branch.
>>> > > > > > > >>>>
>>> > > > > > > >>>> 3. The "dev" branch.
>>> > > > > > > >>>> - This is where non-release-candidate commits are done
>>> > > > > > > >>>> - This is where topic-branches are merged into.
>>> > > > > > > >>>>
>>> > > > > > > >>>> Cutting a release:
>>> > > > > > > >>>> 1. git checkout next && git merge --ff-only dev
>>> > > > > > > >>>> 2. Test test test!
>>> > > > > > > >>>> 3. Fix bugs by committing them directly to "next" and
>>> then
>>> > > > doing a
>>> > > > > > > > non-ff
>>> > > > > > > >>>> merge of next into dev
>>> > > > > > > >>>> 4. Tag release candidate
>>> > > > > > > >>>> 5. Repeat steps 2-4 as necessary
>>> > > > > > > >>>> 6. Tag the release
>>> > > > > > > >>>> 7. Create distribution .zip file
>>> > > > > > > >>>> 8. Test one last time using the dist files
>>> > > > > > > >>>> 9. git checkout stable && git merge --ff-only next
>>> > > > > > > >>>>
>>> > > > > > > >>>>
>>> > > > > > > >>>>
>>> > > > > > > >>>> On Tue, Jan 22, 2013 at 1:59 PM, Braden Shepherdson
>>> > > > > > > >>>> <br...@chromium.org>wrote:
>>> > > > > > > >>>>
>>> > > > > > > >>>>> I think deleting and recreating branches with the same
>>> name
>>> > > can
>>> > > > > > cause
>>> > > > > > > >>>>> badness in git[1] because of remotes. It's not really
>>> the
>>> > > same
>>> > > > > > branch
>>> > > > > > > >> in
>>> > > > > > > >>>>> terms of commits, and git thinks that your old stable
>>> and
>>> > the
>>> > > > new
>>> > > > > > > >> stable
>>> > > > > > > >>>>> differ by all of each of their commits. Tags can be
>>> moved
>>> > > > > > > > arbitrarily,
>>> > > > > > > >>>>> so I
>>> > > > > > > >>>>> think stable makes sense as a tag. I'm not sure about
>>> how
>>> > > best
>>> > > > to
>>> > > > > > > >> handle
>>> > > > > > > >>>>> next.
>>> > > > > > > >>>>>
>>> > > > > > > >>>>> [1]
>>> > > > > > > >
>>> > > > > > >
>>> > > > > >
>>> > > > >
>>> > > >
>>> > >
>>> >
>>> http://stackoverflow.com/questions/11844581/git-delete-and-recreate-branc
>>> > > > > > > >>>>> h
>>> > > > > > > >>>>>
>>> > > > > > > >>>>>
>>> > > > > > > >>>>> On Tue, Jan 22, 2013 at 11:31 AM, Andrew Grieve <
>>> > > > > > > > agrieve@chromium.org
>>> > > > > > > >>>>>> wrote:
>>> > > > > > > >>>>>
>>> > > > > > > >>>>>> Michal's attending hackathons for the week, and I'm
>>> not
>>> > sure
>>> > > > we
>>> > > > > > > > need
>>> > > > > > > >>>>> to
>>> > > > > > > >>>>> do
>>> > > > > > > >>>>>> a hang-out for this, as I think we really are quite
>>> close
>>> > to
>>> > > > > > > >> resolving
>>> > > > > > > >>>>>> this. I'd really like to resolve this ASAP so that we
>>> > don't
>>> > > > need
>>> > > > > > to
>>> > > > > > > >>>>> have
>>> > > > > > > >>>>> a
>>> > > > > > > >>>>>> code-freeze for this release.
>>> > > > > > > >>>>>>
>>> > > > > > > >>>>>> Here's a proposal:
>>> > > > > > > >>>>>>
>>> > > > > > > >>>>>> Cordova repositories have three main branches:
>>> > > > > > > >>>>>> 1. stable
>>> > > > > > > >>>>>> 2. next
>>> > > > > > > >>>>>> 3. dev
>>> > > > > > > >>>>>>
>>> > > > > > > >>>>>> Topic branches also exist for collaborating on
>>> features,
>>> > or
>>> > > > for
>>> > > > > > > >>>>> code-review
>>> > > > > > > >>>>>> purposes.
>>> > > > > > > >>>>>>
>>> > > > > > > >>>>>> There is *no* master branch, so that community-driven
>>> pull
>>> > > > > > requests
>>> > > > > > > >>>>> will
>>> > > > > > > >>>>> be
>>> > > > > > > >>>>>> forced to think about which branch to request against.
>>> > > > > > > >>>>>>
>>> > > > > > > >>>>>> 1. The "stable" branch.
>>> > > > > > > >>>>>> - Sits at the latest stable release of cordova
>>> > > > > > > >>>>>> - No one ever commits to the "stable" branch. It
>>> exists
>>> > only
>>> > > > as
>>> > > > > a
>>> > > > > > > >>>>>> short-cut for checking out the latest stable tag.
>>> > > > > > > >>>>>>
>>> > > > > > > >>>>>> 2. The "next" branch.
>>> > > > > > > >>>>>> - This branch exists only when in the process of
>>> doing a
>>> > > > > release.
>>> > > > > > > >>>>>> - All tags (both stable and RC) are done on this
>>> branch.
>>> > > > > > > >>>>>> - When a stable tag is done:
>>> > > > > > > >>>>>> - The existing "stable" branch is deleted
>>> > > > > > > >>>>>> - A new "stable" branch is created from "next".
>>> > > > > > > >>>>>> - The "next" branch is deleted.
>>> > > > > > > >>>>>>
>>> > > > > > > >>>>>> 3. The "dev" branch.
>>> > > > > > > >>>>>> - This is where all commits are done
>>> > > > > > > >>>>>> - This is where topic-branches are merged into.
>>> > > > > > > >>>>>>
>>> > > > > > > >>>>>> Cutting a release:
>>> > > > > > > >>>>>> 1. Create "next" from the HEAD of "dev"
>>> > > > > > > >>>>>> 2. Test test test!
>>> > > > > > > >>>>>> 3. Fix bugs by committing them to "dev" and then
>>> > > > cherry-picking
>>> > > > > > > > them
>>> > > > > > > >>>>> into
>>> > > > > > > >>>>>> "next"
>>> > > > > > > >>>>>> 4. Tag release candidate
>>> > > > > > > >>>>>> 5. Repeat steps 2-4 as necessary
>>> > > > > > > >>>>>> 6. Tag the release
>>> > > > > > > >>>>>> 7. Create distribution .zip file
>>> > > > > > > >>>>>> 8. Test one last time using the dist files
>>> > > > > > > >>>>>> 9. Delete "stable"
>>> > > > > > > >>>>>> 10. Create a new "stable" by branching from the HEAD
>>> of
>>> > > "next"
>>> > > > > > > >>>>>> 11. Delete the "next" branch
>>> > > > > > > >>>>>>
>>> > > > > > > >>>>>>
>>> > > > > > > >>>>>>
>>> > > > > > > >>>>>> On Wed, Jan 16, 2013 at 10:34 AM, Michal Mocny <
>>> > > > > > > > mmocny@chromium.org>
>>> > > > > > > >>>>>> wrote:
>>> > > > > > > >>>>>>
>>> > > > > > > >>>>>>> Just going to throw out one of my personal
>>> requirements
>>> > for
>>> > > > > > > >> whatever
>>> > > > > > > >>>>>>> proposal we come up with, so it doesn't get lost:
>>> > > > > > > >>>>>>>
>>> > > > > > > >>>>>>> * Feature branches are great for feature work and/or
>>> > large
>>> > > > > > > > sweeping
>>> > > > > > > >>>>>>> changes, as are JIRA bugs for tracking them, but
>>> cordova
>>> > > has
>>> > > > > many
>>> > > > > > > >>>>> many
>>> > > > > > > >>>>>>> trivial issues that could be fixed with "drive-by"
>>> > patches
>>> > > > that
>>> > > > > > > >>>>> require
>>> > > > > > > >>>>>> as
>>> > > > > > > >>>>>>> little friction to commit as possible.
>>> > > > > > > >>>>>>>
>>> > > > > > > >>>>>>>
>>> > > > > > > >>>>>>> On Tue, Jan 15, 2013 at 3:05 PM, Marcel Kinard <
>>> > > > > > > > cmarcelk@gmail.com
>>> > > > > > > >>>
>>> > > > > > > >>>>>> wrote:
>>> > > > > > > >>>>>>>
>>> > > > > > > >>>>>>>> How about if there is a specific straw man proposal
>>> at
>>> > the
>>> > > > > > > >>>>> beginning
>>> > > > > > > >>>>> of
>>> > > > > > > >>>>>>>> the face-time? Then the folks that are in agreement
>>> > won't
>>> > > > need
>>> > > > > > > > to
>>> > > > > > > >>>>> say
>>> > > > > > > >>>>>>>> anything ;-)
>>> > > > > > > >>>>>>>>
>>> > > > > > > >>>>>>>> Seriously, making adjustments to something tangible
>>> is
>>> > > > easier
>>> > > > > > > >> than
>>> > > > > > > >>>>>>>> instantiating it from scratch. A volunteer for a
>>> very
>>> > > simple
>>> > > > > > > >>>>> writeup
>>> > > > > > > >>>>> on
>>> > > > > > > >>>>>>> the
>>> > > > > > > >>>>>>>> wiki?
>>> > > > > > > >>>>>>>>
>>> > > > > > > >>>>>>>> -- Marcel Kinard
>>> > > > > > > >>>>>>>>
>>> > > > > > > >>>>>>>>
>>> > > > > > > >>>>>>>> On 1/14/2013 10:06 PM, Michal Mocny wrote:
>>> > > > > > > >>>>>>>>
>>> > > > > > > >>>>>>>>> Okay gentlemen, I think there have been countless
>>> good
>>> > > > points
>>> > > > > > > >>>>> made
>>> > > > > > > >>>>>> from
>>> > > > > > > >>>>>>>>> all
>>> > > > > > > >>>>>>>>> parties, but also some bike-shedding.
>>> > > > > > > >>>>>>>>>
>>> > > > > > > >>>>>>>>> Perhaps it is time to schedule some face-time to
>>> better
>>> > > > > > > >>>>> articulate
>>> > > > > > > >>>>>> some
>>> > > > > > > >>>>>>> of
>>> > > > > > > >>>>>>>>> the finer points, and to help come to some
>>> consensus?
>>> > > > > > > >>>>>>>>>
>>> > > > > > > >>>>>>>>> -Michal
>>> > > > > > > >
>>> > > > > > >
>>> > > > > >
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > > > --
>>> > > > > @purplecabbage
>>> > > > > risingj.com
>>> > > > >
>>> > > >
>>> > >
>>> >
>>> >
>>> >
>>> > --
>>> > @purplecabbage
>>> > risingj.com
>>> >
>>>
>>
>>
>
--
@purplecabbage
risingj.com
Re: too long to package a release?
Posted by Shazron <sh...@gmail.com>.
Inline image got mangled, here it is linked: http://cl.ly/MOrD
On Thu, Jan 24, 2013 at 1:39 PM, Shazron <sh...@gmail.com> wrote:
> Thanks for the pseudocode Andrew, seems simpler to understand ;) Jesse's
> re-factor makes it even easier. Here's my contrib for those more visually
> inclined:
>
>
> [image: Inline image 2]
>
>
> On Thu, Jan 24, 2013 at 1:29 PM, Andrew Grieve <ag...@chromium.org>wrote:
>
>> Nice! even simpler. :)
>>
>>
>> On Thu, Jan 24, 2013 at 3:44 PM, Jesse <pu...@gmail.com> wrote:
>>
>> > Thanks for clarifying Andrew. et al, I guess I was mis-understanding
>> some
>> > of the earlier discussion around naming stuff.
>> >
>> > So everything is going to master all the time, and we only care about
>> > 'next' if we are inReleaseMode and it is a bug fix?
>> >
>> > if(inReleaseMode && isBugFix) {
>> > commitToBranch('next');
>> > mergeBranch('next').into('master');
>> > }
>> > else {
>> > commitToBranch('master');
>> > }
>> >
>> >
>> >
>> >
>> >
>> > On Thu, Jan 24, 2013 at 12:29 PM, Andrew Grieve <agrieve@chromium.org
>> > >wrote:
>> >
>> > > Just to clarify - there should be *no* using of the git cherry-picking
>> > > command, only git merge.
>> > >
>> > > Jesse - not sure what you're referring to with "branch must be named
>> x".
>> > > The latest revision of the proposal has only two branches: master and
>> > next.
>> > > Do you mean you don't like the name "next"?
>> > >
>> > > Maybe the proposal will seem simpler if put in the form of code :)
>> > >
>> > > if (!inReleaseMode) {
>> > > commitToBranch('master');
>> > > } else {
>> > > if (isBugFix) {
>> > > commitToBranch('next');
>> > > mergeBranch('next').into('master');
>> > > } else {
>> > > commitToBranch('master');
>> > > }
>> > > }
>> > >
>> > >
>> > > On Thu, Jan 24, 2013 at 3:06 PM, Braden Shepherdson <
>> braden@chromium.org
>> > > >wrote:
>> > >
>> > > > Most of the time the flow will be unchanged: push to master. Tagging
>> > > things
>> > > > we already know how to do; that doesn't change.
>> > > >
>> > > > The only new flow for most people is cherrypicking bug fixes from
>> > master
>> > > to
>> > > > next, which we can give examples of. Plus that could remain the
>> > > > responsibility of the main platform maintainers, who are doing the
>> > > tagging.
>> > > >
>> > > > Braden
>> > > >
>> > > >
>> > > > On Thu, Jan 24, 2013 at 2:56 PM, Jesse <pu...@gmail.com>
>> > wrote:
>> > > >
>> > > > > On Thu, Jan 24, 2013 at 11:09 AM, Braden Shepherdson <
>> > > > braden@chromium.org
>> > > > > >wrote:
>> > > > >
>> > > > > > The founding goal we're trying to accomplish here is that we
>> don't
>> > > want
>> > > > > > everyone sitting on changes to be in the next version while we
>> use
>> > > > master
>> > > > > > to prep a release.
>> > > > > >
>> > > > > > I don't think having one branch for prepping the release and
>> > another
>> > > > for
>> > > > > > main development is a lot of bureaucracy.
>> > > > > >
>> > > > >
>> > > > > It is not, the 'branch must be named x' is mainly where I have
>> > > concerns.
>> > > > > Really I just want things simple.
>> > > > >
>> > > > >
>> > > > > >
>> > > > > >
>> > > > > > On Thu, Jan 24, 2013 at 1:57 PM, Jesse MacFadyen <
>> > > > > purplecabbage@gmail.com
>> > > > > > >wrote:
>> > > > > >
>> > > > > > > I have been quietly listening on this thread, but thought I
>> > should
>> > > at
>> > > > > > > least share my opinion.
>> > > > > > >
>> > > > > > > I don't think adding contribution rules helps anyone. Git is
>> > > > > > > complicated enough as it is, and this just all seems like
>> > > > bureaucracy.
>> > > > > > >
>> > > > > > > I think master should always contain the latest stable code,
>> and
>> > be
>> > > > > > > periodically tagged with rc's and versions.
>> > > > > > > All work should be done in personal forks and feature
>> branches.
>> > > > > > > If the latest tag of master is an rc, then we should only be
>> > > merging
>> > > > > > > bugfixes, until the release.
>> > > > > > > Immediately after tagging a version we decide which feature
>> > > branches
>> > > > > > > and pull requests to pull in, and go for it.
>> > > > > > >
>> > > > > > > I don't think this is much different from what we have, but I
>> > think
>> > > > > > > that is good.
>> > > > > > > The suggestions thus far, while interesting, don't increase
>> our
>> > > > > > > velocity in my opinion. Also, I can also pretty much guaranty
>> > I'll
>> > > > > > > screw it up for the next 3-4 versions. ( because I'm dumb )
>> > > > > > >
>> > > > > > > Cheers,
>> > > > > > > Jesse
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > On 2013-01-24, at 5:53 AM, Andrew Grieve <
>> agrieve@chromium.org>
>> > > > wrote:
>> > > > > > >
>> > > > > > > On Wed, Jan 23, 2013 at 4:58 PM, Michael Brooks <
>> > > > > > michael@michaelbrooks.ca
>> > > > > > > >wrote:
>> > > > > > >
>> > > > > > > > Before we move forward, I have a few questions about the "no
>> > > > master"
>> > > > > > > > approach.
>> > > > > > > >
>> > > > > > > > There is *no* master branch, so that community-driven pull
>> > > requests
>> > > > > > will
>> > > > > > > be
>> > > > > > > >> forced to think about which branch to request against.
>> > > > > > > >
>> > > > > > > >
>> > > > > > > > - Andrew, can you cite other projects that do not use a
>> master
>> > > > > branch?
>> > > > > > > This project is my first time using git / github, so I don't
>> have
>> > > > much
>> > > > > to
>> > > > > > > draw from. I was going off of others' suggestions on this
>> thread
>> > > > when I
>> > > > > > > proposed the names.
>> > > > > > >
>> > > > > > >
>> > > > > > > > - On Github, you must have a default branch. If not master,
>> it
>> > > must
>> > > > > be
>> > > > > > > > something else. So, users are not forced to think about the
>> > > branch
>> > > > to
>> > > > > > > send
>> > > > > > > > a pull request again... they will likely just use the
>> default.
>> > > > > > >
>> > > > > > > Hmm, good point. The goal is to get people downloading Cordova
>> > for
>> > > > use
>> > > > > to
>> > > > > > > end up with Stable, and for developers to send pull requests
>> > > against
>> > > > > dev.
>> > > > > > > With a forced default branch, I don't think we can accomplish
>> > this.
>> > > > > > >
>> > > > > > >
>> > > > > > > >
>> > > > > > > > - Why is the "stable" branch not just "master"?
>> > > > > > >
>> > > > > > > My thinking was that it's not obvious whether Master ==
>> bleeding
>> > > > edge,
>> > > > > or
>> > > > > > > Master == Stable version. Using the names "dev" and "stable"
>> > makes
>> > > > it a
>> > > > > > bit
>> > > > > > > clear.
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > So... If github forces us to have a default branch, I'm
>> thinking
>> > > that
>> > > > > > > having users send pull requests against "dev" is more valuable
>> > than
>> > > > > > having
>> > > > > > > people download the latest "stable" by default. If people are
>> > > pulling
>> > > > > > code
>> > > > > > > from github rather than from our release .zip files, then it's
>> > > likely
>> > > > > > they
>> > > > > > > want to hack on it anyways, or that they want the dev version
>> to
>> > > see
>> > > > if
>> > > > > > > bugs are fixed.
>> > > > > > >
>> > > > > > > Soo.... Here's version #3! If anyone can think of how to keep
>> the
>> > > > three
>> > > > > > > branches while addressing being forced to have a default
>> branch,
>> > > feel
>> > > > > > free
>> > > > > > > to speak up! :)
>> > > > > > >
>> > > > > > >
>> > > > > > > Cordova repositories have two main branches:
>> > > > > > > 1. master
>> > > > > > > 2. next
>> > > > > > >
>> > > > > > > Topic branches exist for collaborating on features, or for
>> > > > code-review
>> > > > > > > purposes.
>> > > > > > >
>> > > > > > > Cordova uses tags to label releases.
>> > > > > > > - Each release candidate has a tag. e.g. "2.2.0rc1"
>> > > > > > > - Each release has a tag. e.g. "2.2.0"
>> > > > > > > - The "latest" tag points to the last stable release (this
>> > follows
>> > > > npm
>> > > > > > > conventions)
>> > > > > > >
>> > > > > > >
>> > > > > > > 1. The "next" branch.
>> > > > > > > - This branch is used only when in the process of doing a
>> > release.
>> > > > > > > - All tags are created from this branch.
>> > > > > > > - All release-candidate bug-fixes are done on this branch.
>> > > > > > >
>> > > > > > > 2. The "master" branch.
>> > > > > > > - When not in the release-process, all commits are made here
>> > > > > > > - When in the release-process, all non-bugfix commits are
>> made
>> > > here
>> > > > > > > - This is where topic-branches are merged into.
>> > > > > > >
>> > > > > > > Cutting a release:
>> > > > > > > 1. git checkout next && git merge --ff-only master
>> > > > > > > 2. Test test test!
>> > > > > > > 3. Fix bugs by committing them directly to "next" and then
>> doing
>> > a
>> > > > > non-ff
>> > > > > > > merge of next into master
>> > > > > > > 4. Tag release candidate
>> > > > > > > 5. Repeat steps 2-4 as necessary
>> > > > > > > 6. Tag the release (both by version and by updating the
>> "latest"
>> > > tag)
>> > > > > > > 7. Create distribution .zip file
>> > > > > > > 8. Test one last time using the dist files
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > >
>> > > > > > > > Thanks,
>> > > > > > > > Michael
>> > > > > > > >
>> > > > > > > > On Wed, Jan 23, 2013 at 11:25 AM, Brian LeRoux <b...@brian.io>
>> > > wrote:
>> > > > > > > >
>> > > > > > > >> I'm liking it. Start in 2.5?
>> > > > > > > >>
>> > > > > > > >> On Wed, Jan 23, 2013 at 1:19 PM, Filip Maj <fi...@adobe.com>
>> > > wrote:
>> > > > > > > >>> Looks great Andrew!
>> > > > > > > >>>
>> > > > > > > >>> If everyone's on board, how are we going to test run this?
>> > > Flip a
>> > > > > > > > switch
>> > > > > > > >>> at a certain point, give it a shot with one repo for one
>> RC?
>> > > > > > > >>>
>> > > > > > > >>> On 1/22/13 12:29 PM, "Andrew Grieve" <
>> agrieve@chromium.org>
>> > > > wrote:
>> > > > > > > >>>
>> > > > > > > >>>> Braden, you're right. I've now done some local playing
>> > around
>> > > in
>> > > > > > git,
>> > > > > > > > and
>> > > > > > > >>>> have an updated proposal that uses merges instead of
>> > deleting
>> > > > > > > branches.
>> > > > > > > >>>> PTAL:
>> > > > > > > >>>>
>> > > > > > > >>>> Cordova repositories have three main branches:
>> > > > > > > >>>> 1. stable
>> > > > > > > >>>> 2. next
>> > > > > > > >>>> 3. dev
>> > > > > > > >>>>
>> > > > > > > >>>> Topic branches also exist for collaborating on features,
>> or
>> > > for
>> > > > > > > >>>> code-review
>> > > > > > > >>>> purposes.
>> > > > > > > >>>>
>> > > > > > > >>>> There is *no* master branch, so that community-driven
>> pull
>> > > > > requests
>> > > > > > > > will
>> > > > > > > >>>> be
>> > > > > > > >>>> forced to think about which branch to request against.
>> > > > > > > >>>>
>> > > > > > > >>>> 1. The "stable" branch.
>> > > > > > > >>>> - Sits at the latest stable release of cordova
>> > > > > > > >>>> - This changes only when doing fast-forward merges from
>> > "next"
>> > > > > > > >>>>
>> > > > > > > >>>> 2. The "next" branch.
>> > > > > > > >>>> - This branch is used only when in the process of doing a
>> > > > release.
>> > > > > > > >>>> - All tags (both stable and RC) are done on this branch.
>> > > > > > > >>>> - All release-candidate bug-fixes are done on this
>> branch.
>> > > > > > > >>>>
>> > > > > > > >>>> 3. The "dev" branch.
>> > > > > > > >>>> - This is where non-release-candidate commits are done
>> > > > > > > >>>> - This is where topic-branches are merged into.
>> > > > > > > >>>>
>> > > > > > > >>>> Cutting a release:
>> > > > > > > >>>> 1. git checkout next && git merge --ff-only dev
>> > > > > > > >>>> 2. Test test test!
>> > > > > > > >>>> 3. Fix bugs by committing them directly to "next" and
>> then
>> > > > doing a
>> > > > > > > > non-ff
>> > > > > > > >>>> merge of next into dev
>> > > > > > > >>>> 4. Tag release candidate
>> > > > > > > >>>> 5. Repeat steps 2-4 as necessary
>> > > > > > > >>>> 6. Tag the release
>> > > > > > > >>>> 7. Create distribution .zip file
>> > > > > > > >>>> 8. Test one last time using the dist files
>> > > > > > > >>>> 9. git checkout stable && git merge --ff-only next
>> > > > > > > >>>>
>> > > > > > > >>>>
>> > > > > > > >>>>
>> > > > > > > >>>> On Tue, Jan 22, 2013 at 1:59 PM, Braden Shepherdson
>> > > > > > > >>>> <br...@chromium.org>wrote:
>> > > > > > > >>>>
>> > > > > > > >>>>> I think deleting and recreating branches with the same
>> name
>> > > can
>> > > > > > cause
>> > > > > > > >>>>> badness in git[1] because of remotes. It's not really
>> the
>> > > same
>> > > > > > branch
>> > > > > > > >> in
>> > > > > > > >>>>> terms of commits, and git thinks that your old stable
>> and
>> > the
>> > > > new
>> > > > > > > >> stable
>> > > > > > > >>>>> differ by all of each of their commits. Tags can be
>> moved
>> > > > > > > > arbitrarily,
>> > > > > > > >>>>> so I
>> > > > > > > >>>>> think stable makes sense as a tag. I'm not sure about
>> how
>> > > best
>> > > > to
>> > > > > > > >> handle
>> > > > > > > >>>>> next.
>> > > > > > > >>>>>
>> > > > > > > >>>>> [1]
>> > > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> http://stackoverflow.com/questions/11844581/git-delete-and-recreate-branc
>> > > > > > > >>>>> h
>> > > > > > > >>>>>
>> > > > > > > >>>>>
>> > > > > > > >>>>> On Tue, Jan 22, 2013 at 11:31 AM, Andrew Grieve <
>> > > > > > > > agrieve@chromium.org
>> > > > > > > >>>>>> wrote:
>> > > > > > > >>>>>
>> > > > > > > >>>>>> Michal's attending hackathons for the week, and I'm not
>> > sure
>> > > > we
>> > > > > > > > need
>> > > > > > > >>>>> to
>> > > > > > > >>>>> do
>> > > > > > > >>>>>> a hang-out for this, as I think we really are quite
>> close
>> > to
>> > > > > > > >> resolving
>> > > > > > > >>>>>> this. I'd really like to resolve this ASAP so that we
>> > don't
>> > > > need
>> > > > > > to
>> > > > > > > >>>>> have
>> > > > > > > >>>>> a
>> > > > > > > >>>>>> code-freeze for this release.
>> > > > > > > >>>>>>
>> > > > > > > >>>>>> Here's a proposal:
>> > > > > > > >>>>>>
>> > > > > > > >>>>>> Cordova repositories have three main branches:
>> > > > > > > >>>>>> 1. stable
>> > > > > > > >>>>>> 2. next
>> > > > > > > >>>>>> 3. dev
>> > > > > > > >>>>>>
>> > > > > > > >>>>>> Topic branches also exist for collaborating on
>> features,
>> > or
>> > > > for
>> > > > > > > >>>>> code-review
>> > > > > > > >>>>>> purposes.
>> > > > > > > >>>>>>
>> > > > > > > >>>>>> There is *no* master branch, so that community-driven
>> pull
>> > > > > > requests
>> > > > > > > >>>>> will
>> > > > > > > >>>>> be
>> > > > > > > >>>>>> forced to think about which branch to request against.
>> > > > > > > >>>>>>
>> > > > > > > >>>>>> 1. The "stable" branch.
>> > > > > > > >>>>>> - Sits at the latest stable release of cordova
>> > > > > > > >>>>>> - No one ever commits to the "stable" branch. It exists
>> > only
>> > > > as
>> > > > > a
>> > > > > > > >>>>>> short-cut for checking out the latest stable tag.
>> > > > > > > >>>>>>
>> > > > > > > >>>>>> 2. The "next" branch.
>> > > > > > > >>>>>> - This branch exists only when in the process of doing
>> a
>> > > > > release.
>> > > > > > > >>>>>> - All tags (both stable and RC) are done on this
>> branch.
>> > > > > > > >>>>>> - When a stable tag is done:
>> > > > > > > >>>>>> - The existing "stable" branch is deleted
>> > > > > > > >>>>>> - A new "stable" branch is created from "next".
>> > > > > > > >>>>>> - The "next" branch is deleted.
>> > > > > > > >>>>>>
>> > > > > > > >>>>>> 3. The "dev" branch.
>> > > > > > > >>>>>> - This is where all commits are done
>> > > > > > > >>>>>> - This is where topic-branches are merged into.
>> > > > > > > >>>>>>
>> > > > > > > >>>>>> Cutting a release:
>> > > > > > > >>>>>> 1. Create "next" from the HEAD of "dev"
>> > > > > > > >>>>>> 2. Test test test!
>> > > > > > > >>>>>> 3. Fix bugs by committing them to "dev" and then
>> > > > cherry-picking
>> > > > > > > > them
>> > > > > > > >>>>> into
>> > > > > > > >>>>>> "next"
>> > > > > > > >>>>>> 4. Tag release candidate
>> > > > > > > >>>>>> 5. Repeat steps 2-4 as necessary
>> > > > > > > >>>>>> 6. Tag the release
>> > > > > > > >>>>>> 7. Create distribution .zip file
>> > > > > > > >>>>>> 8. Test one last time using the dist files
>> > > > > > > >>>>>> 9. Delete "stable"
>> > > > > > > >>>>>> 10. Create a new "stable" by branching from the HEAD of
>> > > "next"
>> > > > > > > >>>>>> 11. Delete the "next" branch
>> > > > > > > >>>>>>
>> > > > > > > >>>>>>
>> > > > > > > >>>>>>
>> > > > > > > >>>>>> On Wed, Jan 16, 2013 at 10:34 AM, Michal Mocny <
>> > > > > > > > mmocny@chromium.org>
>> > > > > > > >>>>>> wrote:
>> > > > > > > >>>>>>
>> > > > > > > >>>>>>> Just going to throw out one of my personal
>> requirements
>> > for
>> > > > > > > >> whatever
>> > > > > > > >>>>>>> proposal we come up with, so it doesn't get lost:
>> > > > > > > >>>>>>>
>> > > > > > > >>>>>>> * Feature branches are great for feature work and/or
>> > large
>> > > > > > > > sweeping
>> > > > > > > >>>>>>> changes, as are JIRA bugs for tracking them, but
>> cordova
>> > > has
>> > > > > many
>> > > > > > > >>>>> many
>> > > > > > > >>>>>>> trivial issues that could be fixed with "drive-by"
>> > patches
>> > > > that
>> > > > > > > >>>>> require
>> > > > > > > >>>>>> as
>> > > > > > > >>>>>>> little friction to commit as possible.
>> > > > > > > >>>>>>>
>> > > > > > > >>>>>>>
>> > > > > > > >>>>>>> On Tue, Jan 15, 2013 at 3:05 PM, Marcel Kinard <
>> > > > > > > > cmarcelk@gmail.com
>> > > > > > > >>>
>> > > > > > > >>>>>> wrote:
>> > > > > > > >>>>>>>
>> > > > > > > >>>>>>>> How about if there is a specific straw man proposal
>> at
>> > the
>> > > > > > > >>>>> beginning
>> > > > > > > >>>>> of
>> > > > > > > >>>>>>>> the face-time? Then the folks that are in agreement
>> > won't
>> > > > need
>> > > > > > > > to
>> > > > > > > >>>>> say
>> > > > > > > >>>>>>>> anything ;-)
>> > > > > > > >>>>>>>>
>> > > > > > > >>>>>>>> Seriously, making adjustments to something tangible
>> is
>> > > > easier
>> > > > > > > >> than
>> > > > > > > >>>>>>>> instantiating it from scratch. A volunteer for a very
>> > > simple
>> > > > > > > >>>>> writeup
>> > > > > > > >>>>> on
>> > > > > > > >>>>>>> the
>> > > > > > > >>>>>>>> wiki?
>> > > > > > > >>>>>>>>
>> > > > > > > >>>>>>>> -- Marcel Kinard
>> > > > > > > >>>>>>>>
>> > > > > > > >>>>>>>>
>> > > > > > > >>>>>>>> On 1/14/2013 10:06 PM, Michal Mocny wrote:
>> > > > > > > >>>>>>>>
>> > > > > > > >>>>>>>>> Okay gentlemen, I think there have been countless
>> good
>> > > > points
>> > > > > > > >>>>> made
>> > > > > > > >>>>>> from
>> > > > > > > >>>>>>>>> all
>> > > > > > > >>>>>>>>> parties, but also some bike-shedding.
>> > > > > > > >>>>>>>>>
>> > > > > > > >>>>>>>>> Perhaps it is time to schedule some face-time to
>> better
>> > > > > > > >>>>> articulate
>> > > > > > > >>>>>> some
>> > > > > > > >>>>>>> of
>> > > > > > > >>>>>>>>> the finer points, and to help come to some
>> consensus?
>> > > > > > > >>>>>>>>>
>> > > > > > > >>>>>>>>> -Michal
>> > > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > > --
>> > > > > @purplecabbage
>> > > > > risingj.com
>> > > > >
>> > > >
>> > >
>> >
>> >
>> >
>> > --
>> > @purplecabbage
>> > risingj.com
>> >
>>
>
>
Re: too long to package a release?
Posted by Shazron <sh...@gmail.com>.
Thanks for the pseudocode Andrew, seems simpler to understand ;) Jesse's
re-factor makes it even easier. Here's my contrib for those more visually
inclined:
[image: Inline image 2]
On Thu, Jan 24, 2013 at 1:29 PM, Andrew Grieve <ag...@chromium.org> wrote:
> Nice! even simpler. :)
>
>
> On Thu, Jan 24, 2013 at 3:44 PM, Jesse <pu...@gmail.com> wrote:
>
> > Thanks for clarifying Andrew. et al, I guess I was mis-understanding some
> > of the earlier discussion around naming stuff.
> >
> > So everything is going to master all the time, and we only care about
> > 'next' if we are inReleaseMode and it is a bug fix?
> >
> > if(inReleaseMode && isBugFix) {
> > commitToBranch('next');
> > mergeBranch('next').into('master');
> > }
> > else {
> > commitToBranch('master');
> > }
> >
> >
> >
> >
> >
> > On Thu, Jan 24, 2013 at 12:29 PM, Andrew Grieve <agrieve@chromium.org
> > >wrote:
> >
> > > Just to clarify - there should be *no* using of the git cherry-picking
> > > command, only git merge.
> > >
> > > Jesse - not sure what you're referring to with "branch must be named
> x".
> > > The latest revision of the proposal has only two branches: master and
> > next.
> > > Do you mean you don't like the name "next"?
> > >
> > > Maybe the proposal will seem simpler if put in the form of code :)
> > >
> > > if (!inReleaseMode) {
> > > commitToBranch('master');
> > > } else {
> > > if (isBugFix) {
> > > commitToBranch('next');
> > > mergeBranch('next').into('master');
> > > } else {
> > > commitToBranch('master');
> > > }
> > > }
> > >
> > >
> > > On Thu, Jan 24, 2013 at 3:06 PM, Braden Shepherdson <
> braden@chromium.org
> > > >wrote:
> > >
> > > > Most of the time the flow will be unchanged: push to master. Tagging
> > > things
> > > > we already know how to do; that doesn't change.
> > > >
> > > > The only new flow for most people is cherrypicking bug fixes from
> > master
> > > to
> > > > next, which we can give examples of. Plus that could remain the
> > > > responsibility of the main platform maintainers, who are doing the
> > > tagging.
> > > >
> > > > Braden
> > > >
> > > >
> > > > On Thu, Jan 24, 2013 at 2:56 PM, Jesse <pu...@gmail.com>
> > wrote:
> > > >
> > > > > On Thu, Jan 24, 2013 at 11:09 AM, Braden Shepherdson <
> > > > braden@chromium.org
> > > > > >wrote:
> > > > >
> > > > > > The founding goal we're trying to accomplish here is that we
> don't
> > > want
> > > > > > everyone sitting on changes to be in the next version while we
> use
> > > > master
> > > > > > to prep a release.
> > > > > >
> > > > > > I don't think having one branch for prepping the release and
> > another
> > > > for
> > > > > > main development is a lot of bureaucracy.
> > > > > >
> > > > >
> > > > > It is not, the 'branch must be named x' is mainly where I have
> > > concerns.
> > > > > Really I just want things simple.
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > > On Thu, Jan 24, 2013 at 1:57 PM, Jesse MacFadyen <
> > > > > purplecabbage@gmail.com
> > > > > > >wrote:
> > > > > >
> > > > > > > I have been quietly listening on this thread, but thought I
> > should
> > > at
> > > > > > > least share my opinion.
> > > > > > >
> > > > > > > I don't think adding contribution rules helps anyone. Git is
> > > > > > > complicated enough as it is, and this just all seems like
> > > > bureaucracy.
> > > > > > >
> > > > > > > I think master should always contain the latest stable code,
> and
> > be
> > > > > > > periodically tagged with rc's and versions.
> > > > > > > All work should be done in personal forks and feature branches.
> > > > > > > If the latest tag of master is an rc, then we should only be
> > > merging
> > > > > > > bugfixes, until the release.
> > > > > > > Immediately after tagging a version we decide which feature
> > > branches
> > > > > > > and pull requests to pull in, and go for it.
> > > > > > >
> > > > > > > I don't think this is much different from what we have, but I
> > think
> > > > > > > that is good.
> > > > > > > The suggestions thus far, while interesting, don't increase our
> > > > > > > velocity in my opinion. Also, I can also pretty much guaranty
> > I'll
> > > > > > > screw it up for the next 3-4 versions. ( because I'm dumb )
> > > > > > >
> > > > > > > Cheers,
> > > > > > > Jesse
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On 2013-01-24, at 5:53 AM, Andrew Grieve <agrieve@chromium.org
> >
> > > > wrote:
> > > > > > >
> > > > > > > On Wed, Jan 23, 2013 at 4:58 PM, Michael Brooks <
> > > > > > michael@michaelbrooks.ca
> > > > > > > >wrote:
> > > > > > >
> > > > > > > > Before we move forward, I have a few questions about the "no
> > > > master"
> > > > > > > > approach.
> > > > > > > >
> > > > > > > > There is *no* master branch, so that community-driven pull
> > > requests
> > > > > > will
> > > > > > > be
> > > > > > > >> forced to think about which branch to request against.
> > > > > > > >
> > > > > > > >
> > > > > > > > - Andrew, can you cite other projects that do not use a
> master
> > > > > branch?
> > > > > > > This project is my first time using git / github, so I don't
> have
> > > > much
> > > > > to
> > > > > > > draw from. I was going off of others' suggestions on this
> thread
> > > > when I
> > > > > > > proposed the names.
> > > > > > >
> > > > > > >
> > > > > > > > - On Github, you must have a default branch. If not master,
> it
> > > must
> > > > > be
> > > > > > > > something else. So, users are not forced to think about the
> > > branch
> > > > to
> > > > > > > send
> > > > > > > > a pull request again... they will likely just use the
> default.
> > > > > > >
> > > > > > > Hmm, good point. The goal is to get people downloading Cordova
> > for
> > > > use
> > > > > to
> > > > > > > end up with Stable, and for developers to send pull requests
> > > against
> > > > > dev.
> > > > > > > With a forced default branch, I don't think we can accomplish
> > this.
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > - Why is the "stable" branch not just "master"?
> > > > > > >
> > > > > > > My thinking was that it's not obvious whether Master ==
> bleeding
> > > > edge,
> > > > > or
> > > > > > > Master == Stable version. Using the names "dev" and "stable"
> > makes
> > > > it a
> > > > > > bit
> > > > > > > clear.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > So... If github forces us to have a default branch, I'm
> thinking
> > > that
> > > > > > > having users send pull requests against "dev" is more valuable
> > than
> > > > > > having
> > > > > > > people download the latest "stable" by default. If people are
> > > pulling
> > > > > > code
> > > > > > > from github rather than from our release .zip files, then it's
> > > likely
> > > > > > they
> > > > > > > want to hack on it anyways, or that they want the dev version
> to
> > > see
> > > > if
> > > > > > > bugs are fixed.
> > > > > > >
> > > > > > > Soo.... Here's version #3! If anyone can think of how to keep
> the
> > > > three
> > > > > > > branches while addressing being forced to have a default
> branch,
> > > feel
> > > > > > free
> > > > > > > to speak up! :)
> > > > > > >
> > > > > > >
> > > > > > > Cordova repositories have two main branches:
> > > > > > > 1. master
> > > > > > > 2. next
> > > > > > >
> > > > > > > Topic branches exist for collaborating on features, or for
> > > > code-review
> > > > > > > purposes.
> > > > > > >
> > > > > > > Cordova uses tags to label releases.
> > > > > > > - Each release candidate has a tag. e.g. "2.2.0rc1"
> > > > > > > - Each release has a tag. e.g. "2.2.0"
> > > > > > > - The "latest" tag points to the last stable release (this
> > follows
> > > > npm
> > > > > > > conventions)
> > > > > > >
> > > > > > >
> > > > > > > 1. The "next" branch.
> > > > > > > - This branch is used only when in the process of doing a
> > release.
> > > > > > > - All tags are created from this branch.
> > > > > > > - All release-candidate bug-fixes are done on this branch.
> > > > > > >
> > > > > > > 2. The "master" branch.
> > > > > > > - When not in the release-process, all commits are made here
> > > > > > > - When in the release-process, all non-bugfix commits are made
> > > here
> > > > > > > - This is where topic-branches are merged into.
> > > > > > >
> > > > > > > Cutting a release:
> > > > > > > 1. git checkout next && git merge --ff-only master
> > > > > > > 2. Test test test!
> > > > > > > 3. Fix bugs by committing them directly to "next" and then
> doing
> > a
> > > > > non-ff
> > > > > > > merge of next into master
> > > > > > > 4. Tag release candidate
> > > > > > > 5. Repeat steps 2-4 as necessary
> > > > > > > 6. Tag the release (both by version and by updating the
> "latest"
> > > tag)
> > > > > > > 7. Create distribution .zip file
> > > > > > > 8. Test one last time using the dist files
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Michael
> > > > > > > >
> > > > > > > > On Wed, Jan 23, 2013 at 11:25 AM, Brian LeRoux <b...@brian.io>
> > > wrote:
> > > > > > > >
> > > > > > > >> I'm liking it. Start in 2.5?
> > > > > > > >>
> > > > > > > >> On Wed, Jan 23, 2013 at 1:19 PM, Filip Maj <fi...@adobe.com>
> > > wrote:
> > > > > > > >>> Looks great Andrew!
> > > > > > > >>>
> > > > > > > >>> If everyone's on board, how are we going to test run this?
> > > Flip a
> > > > > > > > switch
> > > > > > > >>> at a certain point, give it a shot with one repo for one
> RC?
> > > > > > > >>>
> > > > > > > >>> On 1/22/13 12:29 PM, "Andrew Grieve" <agrieve@chromium.org
> >
> > > > wrote:
> > > > > > > >>>
> > > > > > > >>>> Braden, you're right. I've now done some local playing
> > around
> > > in
> > > > > > git,
> > > > > > > > and
> > > > > > > >>>> have an updated proposal that uses merges instead of
> > deleting
> > > > > > > branches.
> > > > > > > >>>> PTAL:
> > > > > > > >>>>
> > > > > > > >>>> Cordova repositories have three main branches:
> > > > > > > >>>> 1. stable
> > > > > > > >>>> 2. next
> > > > > > > >>>> 3. dev
> > > > > > > >>>>
> > > > > > > >>>> Topic branches also exist for collaborating on features,
> or
> > > for
> > > > > > > >>>> code-review
> > > > > > > >>>> purposes.
> > > > > > > >>>>
> > > > > > > >>>> There is *no* master branch, so that community-driven pull
> > > > > requests
> > > > > > > > will
> > > > > > > >>>> be
> > > > > > > >>>> forced to think about which branch to request against.
> > > > > > > >>>>
> > > > > > > >>>> 1. The "stable" branch.
> > > > > > > >>>> - Sits at the latest stable release of cordova
> > > > > > > >>>> - This changes only when doing fast-forward merges from
> > "next"
> > > > > > > >>>>
> > > > > > > >>>> 2. The "next" branch.
> > > > > > > >>>> - This branch is used only when in the process of doing a
> > > > release.
> > > > > > > >>>> - All tags (both stable and RC) are done on this branch.
> > > > > > > >>>> - All release-candidate bug-fixes are done on this branch.
> > > > > > > >>>>
> > > > > > > >>>> 3. The "dev" branch.
> > > > > > > >>>> - This is where non-release-candidate commits are done
> > > > > > > >>>> - This is where topic-branches are merged into.
> > > > > > > >>>>
> > > > > > > >>>> Cutting a release:
> > > > > > > >>>> 1. git checkout next && git merge --ff-only dev
> > > > > > > >>>> 2. Test test test!
> > > > > > > >>>> 3. Fix bugs by committing them directly to "next" and then
> > > > doing a
> > > > > > > > non-ff
> > > > > > > >>>> merge of next into dev
> > > > > > > >>>> 4. Tag release candidate
> > > > > > > >>>> 5. Repeat steps 2-4 as necessary
> > > > > > > >>>> 6. Tag the release
> > > > > > > >>>> 7. Create distribution .zip file
> > > > > > > >>>> 8. Test one last time using the dist files
> > > > > > > >>>> 9. git checkout stable && git merge --ff-only next
> > > > > > > >>>>
> > > > > > > >>>>
> > > > > > > >>>>
> > > > > > > >>>> On Tue, Jan 22, 2013 at 1:59 PM, Braden Shepherdson
> > > > > > > >>>> <br...@chromium.org>wrote:
> > > > > > > >>>>
> > > > > > > >>>>> I think deleting and recreating branches with the same
> name
> > > can
> > > > > > cause
> > > > > > > >>>>> badness in git[1] because of remotes. It's not really the
> > > same
> > > > > > branch
> > > > > > > >> in
> > > > > > > >>>>> terms of commits, and git thinks that your old stable and
> > the
> > > > new
> > > > > > > >> stable
> > > > > > > >>>>> differ by all of each of their commits. Tags can be moved
> > > > > > > > arbitrarily,
> > > > > > > >>>>> so I
> > > > > > > >>>>> think stable makes sense as a tag. I'm not sure about how
> > > best
> > > > to
> > > > > > > >> handle
> > > > > > > >>>>> next.
> > > > > > > >>>>>
> > > > > > > >>>>> [1]
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://stackoverflow.com/questions/11844581/git-delete-and-recreate-branc
> > > > > > > >>>>> h
> > > > > > > >>>>>
> > > > > > > >>>>>
> > > > > > > >>>>> On Tue, Jan 22, 2013 at 11:31 AM, Andrew Grieve <
> > > > > > > > agrieve@chromium.org
> > > > > > > >>>>>> wrote:
> > > > > > > >>>>>
> > > > > > > >>>>>> Michal's attending hackathons for the week, and I'm not
> > sure
> > > > we
> > > > > > > > need
> > > > > > > >>>>> to
> > > > > > > >>>>> do
> > > > > > > >>>>>> a hang-out for this, as I think we really are quite
> close
> > to
> > > > > > > >> resolving
> > > > > > > >>>>>> this. I'd really like to resolve this ASAP so that we
> > don't
> > > > need
> > > > > > to
> > > > > > > >>>>> have
> > > > > > > >>>>> a
> > > > > > > >>>>>> code-freeze for this release.
> > > > > > > >>>>>>
> > > > > > > >>>>>> Here's a proposal:
> > > > > > > >>>>>>
> > > > > > > >>>>>> Cordova repositories have three main branches:
> > > > > > > >>>>>> 1. stable
> > > > > > > >>>>>> 2. next
> > > > > > > >>>>>> 3. dev
> > > > > > > >>>>>>
> > > > > > > >>>>>> Topic branches also exist for collaborating on features,
> > or
> > > > for
> > > > > > > >>>>> code-review
> > > > > > > >>>>>> purposes.
> > > > > > > >>>>>>
> > > > > > > >>>>>> There is *no* master branch, so that community-driven
> pull
> > > > > > requests
> > > > > > > >>>>> will
> > > > > > > >>>>> be
> > > > > > > >>>>>> forced to think about which branch to request against.
> > > > > > > >>>>>>
> > > > > > > >>>>>> 1. The "stable" branch.
> > > > > > > >>>>>> - Sits at the latest stable release of cordova
> > > > > > > >>>>>> - No one ever commits to the "stable" branch. It exists
> > only
> > > > as
> > > > > a
> > > > > > > >>>>>> short-cut for checking out the latest stable tag.
> > > > > > > >>>>>>
> > > > > > > >>>>>> 2. The "next" branch.
> > > > > > > >>>>>> - This branch exists only when in the process of doing a
> > > > > release.
> > > > > > > >>>>>> - All tags (both stable and RC) are done on this branch.
> > > > > > > >>>>>> - When a stable tag is done:
> > > > > > > >>>>>> - The existing "stable" branch is deleted
> > > > > > > >>>>>> - A new "stable" branch is created from "next".
> > > > > > > >>>>>> - The "next" branch is deleted.
> > > > > > > >>>>>>
> > > > > > > >>>>>> 3. The "dev" branch.
> > > > > > > >>>>>> - This is where all commits are done
> > > > > > > >>>>>> - This is where topic-branches are merged into.
> > > > > > > >>>>>>
> > > > > > > >>>>>> Cutting a release:
> > > > > > > >>>>>> 1. Create "next" from the HEAD of "dev"
> > > > > > > >>>>>> 2. Test test test!
> > > > > > > >>>>>> 3. Fix bugs by committing them to "dev" and then
> > > > cherry-picking
> > > > > > > > them
> > > > > > > >>>>> into
> > > > > > > >>>>>> "next"
> > > > > > > >>>>>> 4. Tag release candidate
> > > > > > > >>>>>> 5. Repeat steps 2-4 as necessary
> > > > > > > >>>>>> 6. Tag the release
> > > > > > > >>>>>> 7. Create distribution .zip file
> > > > > > > >>>>>> 8. Test one last time using the dist files
> > > > > > > >>>>>> 9. Delete "stable"
> > > > > > > >>>>>> 10. Create a new "stable" by branching from the HEAD of
> > > "next"
> > > > > > > >>>>>> 11. Delete the "next" branch
> > > > > > > >>>>>>
> > > > > > > >>>>>>
> > > > > > > >>>>>>
> > > > > > > >>>>>> On Wed, Jan 16, 2013 at 10:34 AM, Michal Mocny <
> > > > > > > > mmocny@chromium.org>
> > > > > > > >>>>>> wrote:
> > > > > > > >>>>>>
> > > > > > > >>>>>>> Just going to throw out one of my personal requirements
> > for
> > > > > > > >> whatever
> > > > > > > >>>>>>> proposal we come up with, so it doesn't get lost:
> > > > > > > >>>>>>>
> > > > > > > >>>>>>> * Feature branches are great for feature work and/or
> > large
> > > > > > > > sweeping
> > > > > > > >>>>>>> changes, as are JIRA bugs for tracking them, but
> cordova
> > > has
> > > > > many
> > > > > > > >>>>> many
> > > > > > > >>>>>>> trivial issues that could be fixed with "drive-by"
> > patches
> > > > that
> > > > > > > >>>>> require
> > > > > > > >>>>>> as
> > > > > > > >>>>>>> little friction to commit as possible.
> > > > > > > >>>>>>>
> > > > > > > >>>>>>>
> > > > > > > >>>>>>> On Tue, Jan 15, 2013 at 3:05 PM, Marcel Kinard <
> > > > > > > > cmarcelk@gmail.com
> > > > > > > >>>
> > > > > > > >>>>>> wrote:
> > > > > > > >>>>>>>
> > > > > > > >>>>>>>> How about if there is a specific straw man proposal at
> > the
> > > > > > > >>>>> beginning
> > > > > > > >>>>> of
> > > > > > > >>>>>>>> the face-time? Then the folks that are in agreement
> > won't
> > > > need
> > > > > > > > to
> > > > > > > >>>>> say
> > > > > > > >>>>>>>> anything ;-)
> > > > > > > >>>>>>>>
> > > > > > > >>>>>>>> Seriously, making adjustments to something tangible is
> > > > easier
> > > > > > > >> than
> > > > > > > >>>>>>>> instantiating it from scratch. A volunteer for a very
> > > simple
> > > > > > > >>>>> writeup
> > > > > > > >>>>> on
> > > > > > > >>>>>>> the
> > > > > > > >>>>>>>> wiki?
> > > > > > > >>>>>>>>
> > > > > > > >>>>>>>> -- Marcel Kinard
> > > > > > > >>>>>>>>
> > > > > > > >>>>>>>>
> > > > > > > >>>>>>>> On 1/14/2013 10:06 PM, Michal Mocny wrote:
> > > > > > > >>>>>>>>
> > > > > > > >>>>>>>>> Okay gentlemen, I think there have been countless
> good
> > > > points
> > > > > > > >>>>> made
> > > > > > > >>>>>> from
> > > > > > > >>>>>>>>> all
> > > > > > > >>>>>>>>> parties, but also some bike-shedding.
> > > > > > > >>>>>>>>>
> > > > > > > >>>>>>>>> Perhaps it is time to schedule some face-time to
> better
> > > > > > > >>>>> articulate
> > > > > > > >>>>>> some
> > > > > > > >>>>>>> of
> > > > > > > >>>>>>>>> the finer points, and to help come to some consensus?
> > > > > > > >>>>>>>>>
> > > > > > > >>>>>>>>> -Michal
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > @purplecabbage
> > > > > risingj.com
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > @purplecabbage
> > risingj.com
> >
>
Re: too long to package a release?
Posted by Andrew Grieve <ag...@chromium.org>.
Nice! even simpler. :)
On Thu, Jan 24, 2013 at 3:44 PM, Jesse <pu...@gmail.com> wrote:
> Thanks for clarifying Andrew. et al, I guess I was mis-understanding some
> of the earlier discussion around naming stuff.
>
> So everything is going to master all the time, and we only care about
> 'next' if we are inReleaseMode and it is a bug fix?
>
> if(inReleaseMode && isBugFix) {
> commitToBranch('next');
> mergeBranch('next').into('master');
> }
> else {
> commitToBranch('master');
> }
>
>
>
>
>
> On Thu, Jan 24, 2013 at 12:29 PM, Andrew Grieve <agrieve@chromium.org
> >wrote:
>
> > Just to clarify - there should be *no* using of the git cherry-picking
> > command, only git merge.
> >
> > Jesse - not sure what you're referring to with "branch must be named x".
> > The latest revision of the proposal has only two branches: master and
> next.
> > Do you mean you don't like the name "next"?
> >
> > Maybe the proposal will seem simpler if put in the form of code :)
> >
> > if (!inReleaseMode) {
> > commitToBranch('master');
> > } else {
> > if (isBugFix) {
> > commitToBranch('next');
> > mergeBranch('next').into('master');
> > } else {
> > commitToBranch('master');
> > }
> > }
> >
> >
> > On Thu, Jan 24, 2013 at 3:06 PM, Braden Shepherdson <braden@chromium.org
> > >wrote:
> >
> > > Most of the time the flow will be unchanged: push to master. Tagging
> > things
> > > we already know how to do; that doesn't change.
> > >
> > > The only new flow for most people is cherrypicking bug fixes from
> master
> > to
> > > next, which we can give examples of. Plus that could remain the
> > > responsibility of the main platform maintainers, who are doing the
> > tagging.
> > >
> > > Braden
> > >
> > >
> > > On Thu, Jan 24, 2013 at 2:56 PM, Jesse <pu...@gmail.com>
> wrote:
> > >
> > > > On Thu, Jan 24, 2013 at 11:09 AM, Braden Shepherdson <
> > > braden@chromium.org
> > > > >wrote:
> > > >
> > > > > The founding goal we're trying to accomplish here is that we don't
> > want
> > > > > everyone sitting on changes to be in the next version while we use
> > > master
> > > > > to prep a release.
> > > > >
> > > > > I don't think having one branch for prepping the release and
> another
> > > for
> > > > > main development is a lot of bureaucracy.
> > > > >
> > > >
> > > > It is not, the 'branch must be named x' is mainly where I have
> > concerns.
> > > > Really I just want things simple.
> > > >
> > > >
> > > > >
> > > > >
> > > > > On Thu, Jan 24, 2013 at 1:57 PM, Jesse MacFadyen <
> > > > purplecabbage@gmail.com
> > > > > >wrote:
> > > > >
> > > > > > I have been quietly listening on this thread, but thought I
> should
> > at
> > > > > > least share my opinion.
> > > > > >
> > > > > > I don't think adding contribution rules helps anyone. Git is
> > > > > > complicated enough as it is, and this just all seems like
> > > bureaucracy.
> > > > > >
> > > > > > I think master should always contain the latest stable code, and
> be
> > > > > > periodically tagged with rc's and versions.
> > > > > > All work should be done in personal forks and feature branches.
> > > > > > If the latest tag of master is an rc, then we should only be
> > merging
> > > > > > bugfixes, until the release.
> > > > > > Immediately after tagging a version we decide which feature
> > branches
> > > > > > and pull requests to pull in, and go for it.
> > > > > >
> > > > > > I don't think this is much different from what we have, but I
> think
> > > > > > that is good.
> > > > > > The suggestions thus far, while interesting, don't increase our
> > > > > > velocity in my opinion. Also, I can also pretty much guaranty
> I'll
> > > > > > screw it up for the next 3-4 versions. ( because I'm dumb )
> > > > > >
> > > > > > Cheers,
> > > > > > Jesse
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 2013-01-24, at 5:53 AM, Andrew Grieve <ag...@chromium.org>
> > > wrote:
> > > > > >
> > > > > > On Wed, Jan 23, 2013 at 4:58 PM, Michael Brooks <
> > > > > michael@michaelbrooks.ca
> > > > > > >wrote:
> > > > > >
> > > > > > > Before we move forward, I have a few questions about the "no
> > > master"
> > > > > > > approach.
> > > > > > >
> > > > > > > There is *no* master branch, so that community-driven pull
> > requests
> > > > > will
> > > > > > be
> > > > > > >> forced to think about which branch to request against.
> > > > > > >
> > > > > > >
> > > > > > > - Andrew, can you cite other projects that do not use a master
> > > > branch?
> > > > > > This project is my first time using git / github, so I don't have
> > > much
> > > > to
> > > > > > draw from. I was going off of others' suggestions on this thread
> > > when I
> > > > > > proposed the names.
> > > > > >
> > > > > >
> > > > > > > - On Github, you must have a default branch. If not master, it
> > must
> > > > be
> > > > > > > something else. So, users are not forced to think about the
> > branch
> > > to
> > > > > > send
> > > > > > > a pull request again... they will likely just use the default.
> > > > > >
> > > > > > Hmm, good point. The goal is to get people downloading Cordova
> for
> > > use
> > > > to
> > > > > > end up with Stable, and for developers to send pull requests
> > against
> > > > dev.
> > > > > > With a forced default branch, I don't think we can accomplish
> this.
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > - Why is the "stable" branch not just "master"?
> > > > > >
> > > > > > My thinking was that it's not obvious whether Master == bleeding
> > > edge,
> > > > or
> > > > > > Master == Stable version. Using the names "dev" and "stable"
> makes
> > > it a
> > > > > bit
> > > > > > clear.
> > > > > >
> > > > > >
> > > > > >
> > > > > > So... If github forces us to have a default branch, I'm thinking
> > that
> > > > > > having users send pull requests against "dev" is more valuable
> than
> > > > > having
> > > > > > people download the latest "stable" by default. If people are
> > pulling
> > > > > code
> > > > > > from github rather than from our release .zip files, then it's
> > likely
> > > > > they
> > > > > > want to hack on it anyways, or that they want the dev version to
> > see
> > > if
> > > > > > bugs are fixed.
> > > > > >
> > > > > > Soo.... Here's version #3! If anyone can think of how to keep the
> > > three
> > > > > > branches while addressing being forced to have a default branch,
> > feel
> > > > > free
> > > > > > to speak up! :)
> > > > > >
> > > > > >
> > > > > > Cordova repositories have two main branches:
> > > > > > 1. master
> > > > > > 2. next
> > > > > >
> > > > > > Topic branches exist for collaborating on features, or for
> > > code-review
> > > > > > purposes.
> > > > > >
> > > > > > Cordova uses tags to label releases.
> > > > > > - Each release candidate has a tag. e.g. "2.2.0rc1"
> > > > > > - Each release has a tag. e.g. "2.2.0"
> > > > > > - The "latest" tag points to the last stable release (this
> follows
> > > npm
> > > > > > conventions)
> > > > > >
> > > > > >
> > > > > > 1. The "next" branch.
> > > > > > - This branch is used only when in the process of doing a
> release.
> > > > > > - All tags are created from this branch.
> > > > > > - All release-candidate bug-fixes are done on this branch.
> > > > > >
> > > > > > 2. The "master" branch.
> > > > > > - When not in the release-process, all commits are made here
> > > > > > - When in the release-process, all non-bugfix commits are made
> > here
> > > > > > - This is where topic-branches are merged into.
> > > > > >
> > > > > > Cutting a release:
> > > > > > 1. git checkout next && git merge --ff-only master
> > > > > > 2. Test test test!
> > > > > > 3. Fix bugs by committing them directly to "next" and then doing
> a
> > > > non-ff
> > > > > > merge of next into master
> > > > > > 4. Tag release candidate
> > > > > > 5. Repeat steps 2-4 as necessary
> > > > > > 6. Tag the release (both by version and by updating the "latest"
> > tag)
> > > > > > 7. Create distribution .zip file
> > > > > > 8. Test one last time using the dist files
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Michael
> > > > > > >
> > > > > > > On Wed, Jan 23, 2013 at 11:25 AM, Brian LeRoux <b...@brian.io>
> > wrote:
> > > > > > >
> > > > > > >> I'm liking it. Start in 2.5?
> > > > > > >>
> > > > > > >> On Wed, Jan 23, 2013 at 1:19 PM, Filip Maj <fi...@adobe.com>
> > wrote:
> > > > > > >>> Looks great Andrew!
> > > > > > >>>
> > > > > > >>> If everyone's on board, how are we going to test run this?
> > Flip a
> > > > > > > switch
> > > > > > >>> at a certain point, give it a shot with one repo for one RC?
> > > > > > >>>
> > > > > > >>> On 1/22/13 12:29 PM, "Andrew Grieve" <ag...@chromium.org>
> > > wrote:
> > > > > > >>>
> > > > > > >>>> Braden, you're right. I've now done some local playing
> around
> > in
> > > > > git,
> > > > > > > and
> > > > > > >>>> have an updated proposal that uses merges instead of
> deleting
> > > > > > branches.
> > > > > > >>>> PTAL:
> > > > > > >>>>
> > > > > > >>>> Cordova repositories have three main branches:
> > > > > > >>>> 1. stable
> > > > > > >>>> 2. next
> > > > > > >>>> 3. dev
> > > > > > >>>>
> > > > > > >>>> Topic branches also exist for collaborating on features, or
> > for
> > > > > > >>>> code-review
> > > > > > >>>> purposes.
> > > > > > >>>>
> > > > > > >>>> There is *no* master branch, so that community-driven pull
> > > > requests
> > > > > > > will
> > > > > > >>>> be
> > > > > > >>>> forced to think about which branch to request against.
> > > > > > >>>>
> > > > > > >>>> 1. The "stable" branch.
> > > > > > >>>> - Sits at the latest stable release of cordova
> > > > > > >>>> - This changes only when doing fast-forward merges from
> "next"
> > > > > > >>>>
> > > > > > >>>> 2. The "next" branch.
> > > > > > >>>> - This branch is used only when in the process of doing a
> > > release.
> > > > > > >>>> - All tags (both stable and RC) are done on this branch.
> > > > > > >>>> - All release-candidate bug-fixes are done on this branch.
> > > > > > >>>>
> > > > > > >>>> 3. The "dev" branch.
> > > > > > >>>> - This is where non-release-candidate commits are done
> > > > > > >>>> - This is where topic-branches are merged into.
> > > > > > >>>>
> > > > > > >>>> Cutting a release:
> > > > > > >>>> 1. git checkout next && git merge --ff-only dev
> > > > > > >>>> 2. Test test test!
> > > > > > >>>> 3. Fix bugs by committing them directly to "next" and then
> > > doing a
> > > > > > > non-ff
> > > > > > >>>> merge of next into dev
> > > > > > >>>> 4. Tag release candidate
> > > > > > >>>> 5. Repeat steps 2-4 as necessary
> > > > > > >>>> 6. Tag the release
> > > > > > >>>> 7. Create distribution .zip file
> > > > > > >>>> 8. Test one last time using the dist files
> > > > > > >>>> 9. git checkout stable && git merge --ff-only next
> > > > > > >>>>
> > > > > > >>>>
> > > > > > >>>>
> > > > > > >>>> On Tue, Jan 22, 2013 at 1:59 PM, Braden Shepherdson
> > > > > > >>>> <br...@chromium.org>wrote:
> > > > > > >>>>
> > > > > > >>>>> I think deleting and recreating branches with the same name
> > can
> > > > > cause
> > > > > > >>>>> badness in git[1] because of remotes. It's not really the
> > same
> > > > > branch
> > > > > > >> in
> > > > > > >>>>> terms of commits, and git thinks that your old stable and
> the
> > > new
> > > > > > >> stable
> > > > > > >>>>> differ by all of each of their commits. Tags can be moved
> > > > > > > arbitrarily,
> > > > > > >>>>> so I
> > > > > > >>>>> think stable makes sense as a tag. I'm not sure about how
> > best
> > > to
> > > > > > >> handle
> > > > > > >>>>> next.
> > > > > > >>>>>
> > > > > > >>>>> [1]
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://stackoverflow.com/questions/11844581/git-delete-and-recreate-branc
> > > > > > >>>>> h
> > > > > > >>>>>
> > > > > > >>>>>
> > > > > > >>>>> On Tue, Jan 22, 2013 at 11:31 AM, Andrew Grieve <
> > > > > > > agrieve@chromium.org
> > > > > > >>>>>> wrote:
> > > > > > >>>>>
> > > > > > >>>>>> Michal's attending hackathons for the week, and I'm not
> sure
> > > we
> > > > > > > need
> > > > > > >>>>> to
> > > > > > >>>>> do
> > > > > > >>>>>> a hang-out for this, as I think we really are quite close
> to
> > > > > > >> resolving
> > > > > > >>>>>> this. I'd really like to resolve this ASAP so that we
> don't
> > > need
> > > > > to
> > > > > > >>>>> have
> > > > > > >>>>> a
> > > > > > >>>>>> code-freeze for this release.
> > > > > > >>>>>>
> > > > > > >>>>>> Here's a proposal:
> > > > > > >>>>>>
> > > > > > >>>>>> Cordova repositories have three main branches:
> > > > > > >>>>>> 1. stable
> > > > > > >>>>>> 2. next
> > > > > > >>>>>> 3. dev
> > > > > > >>>>>>
> > > > > > >>>>>> Topic branches also exist for collaborating on features,
> or
> > > for
> > > > > > >>>>> code-review
> > > > > > >>>>>> purposes.
> > > > > > >>>>>>
> > > > > > >>>>>> There is *no* master branch, so that community-driven pull
> > > > > requests
> > > > > > >>>>> will
> > > > > > >>>>> be
> > > > > > >>>>>> forced to think about which branch to request against.
> > > > > > >>>>>>
> > > > > > >>>>>> 1. The "stable" branch.
> > > > > > >>>>>> - Sits at the latest stable release of cordova
> > > > > > >>>>>> - No one ever commits to the "stable" branch. It exists
> only
> > > as
> > > > a
> > > > > > >>>>>> short-cut for checking out the latest stable tag.
> > > > > > >>>>>>
> > > > > > >>>>>> 2. The "next" branch.
> > > > > > >>>>>> - This branch exists only when in the process of doing a
> > > > release.
> > > > > > >>>>>> - All tags (both stable and RC) are done on this branch.
> > > > > > >>>>>> - When a stable tag is done:
> > > > > > >>>>>> - The existing "stable" branch is deleted
> > > > > > >>>>>> - A new "stable" branch is created from "next".
> > > > > > >>>>>> - The "next" branch is deleted.
> > > > > > >>>>>>
> > > > > > >>>>>> 3. The "dev" branch.
> > > > > > >>>>>> - This is where all commits are done
> > > > > > >>>>>> - This is where topic-branches are merged into.
> > > > > > >>>>>>
> > > > > > >>>>>> Cutting a release:
> > > > > > >>>>>> 1. Create "next" from the HEAD of "dev"
> > > > > > >>>>>> 2. Test test test!
> > > > > > >>>>>> 3. Fix bugs by committing them to "dev" and then
> > > cherry-picking
> > > > > > > them
> > > > > > >>>>> into
> > > > > > >>>>>> "next"
> > > > > > >>>>>> 4. Tag release candidate
> > > > > > >>>>>> 5. Repeat steps 2-4 as necessary
> > > > > > >>>>>> 6. Tag the release
> > > > > > >>>>>> 7. Create distribution .zip file
> > > > > > >>>>>> 8. Test one last time using the dist files
> > > > > > >>>>>> 9. Delete "stable"
> > > > > > >>>>>> 10. Create a new "stable" by branching from the HEAD of
> > "next"
> > > > > > >>>>>> 11. Delete the "next" branch
> > > > > > >>>>>>
> > > > > > >>>>>>
> > > > > > >>>>>>
> > > > > > >>>>>> On Wed, Jan 16, 2013 at 10:34 AM, Michal Mocny <
> > > > > > > mmocny@chromium.org>
> > > > > > >>>>>> wrote:
> > > > > > >>>>>>
> > > > > > >>>>>>> Just going to throw out one of my personal requirements
> for
> > > > > > >> whatever
> > > > > > >>>>>>> proposal we come up with, so it doesn't get lost:
> > > > > > >>>>>>>
> > > > > > >>>>>>> * Feature branches are great for feature work and/or
> large
> > > > > > > sweeping
> > > > > > >>>>>>> changes, as are JIRA bugs for tracking them, but cordova
> > has
> > > > many
> > > > > > >>>>> many
> > > > > > >>>>>>> trivial issues that could be fixed with "drive-by"
> patches
> > > that
> > > > > > >>>>> require
> > > > > > >>>>>> as
> > > > > > >>>>>>> little friction to commit as possible.
> > > > > > >>>>>>>
> > > > > > >>>>>>>
> > > > > > >>>>>>> On Tue, Jan 15, 2013 at 3:05 PM, Marcel Kinard <
> > > > > > > cmarcelk@gmail.com
> > > > > > >>>
> > > > > > >>>>>> wrote:
> > > > > > >>>>>>>
> > > > > > >>>>>>>> How about if there is a specific straw man proposal at
> the
> > > > > > >>>>> beginning
> > > > > > >>>>> of
> > > > > > >>>>>>>> the face-time? Then the folks that are in agreement
> won't
> > > need
> > > > > > > to
> > > > > > >>>>> say
> > > > > > >>>>>>>> anything ;-)
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> Seriously, making adjustments to something tangible is
> > > easier
> > > > > > >> than
> > > > > > >>>>>>>> instantiating it from scratch. A volunteer for a very
> > simple
> > > > > > >>>>> writeup
> > > > > > >>>>> on
> > > > > > >>>>>>> the
> > > > > > >>>>>>>> wiki?
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> -- Marcel Kinard
> > > > > > >>>>>>>>
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> On 1/14/2013 10:06 PM, Michal Mocny wrote:
> > > > > > >>>>>>>>
> > > > > > >>>>>>>>> Okay gentlemen, I think there have been countless good
> > > points
> > > > > > >>>>> made
> > > > > > >>>>>> from
> > > > > > >>>>>>>>> all
> > > > > > >>>>>>>>> parties, but also some bike-shedding.
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>> Perhaps it is time to schedule some face-time to better
> > > > > > >>>>> articulate
> > > > > > >>>>>> some
> > > > > > >>>>>>> of
> > > > > > >>>>>>>>> the finer points, and to help come to some consensus?
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>> -Michal
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > @purplecabbage
> > > > risingj.com
> > > >
> > >
> >
>
>
>
> --
> @purplecabbage
> risingj.com
>
Re: too long to package a release?
Posted by Jesse <pu...@gmail.com>.
Thanks for clarifying Andrew. et al, I guess I was mis-understanding some
of the earlier discussion around naming stuff.
So everything is going to master all the time, and we only care about
'next' if we are inReleaseMode and it is a bug fix?
if(inReleaseMode && isBugFix) {
commitToBranch('next');
mergeBranch('next').into('master');
}
else {
commitToBranch('master');
}
On Thu, Jan 24, 2013 at 12:29 PM, Andrew Grieve <ag...@chromium.org>wrote:
> Just to clarify - there should be *no* using of the git cherry-picking
> command, only git merge.
>
> Jesse - not sure what you're referring to with "branch must be named x".
> The latest revision of the proposal has only two branches: master and next.
> Do you mean you don't like the name "next"?
>
> Maybe the proposal will seem simpler if put in the form of code :)
>
> if (!inReleaseMode) {
> commitToBranch('master');
> } else {
> if (isBugFix) {
> commitToBranch('next');
> mergeBranch('next').into('master');
> } else {
> commitToBranch('master');
> }
> }
>
>
> On Thu, Jan 24, 2013 at 3:06 PM, Braden Shepherdson <braden@chromium.org
> >wrote:
>
> > Most of the time the flow will be unchanged: push to master. Tagging
> things
> > we already know how to do; that doesn't change.
> >
> > The only new flow for most people is cherrypicking bug fixes from master
> to
> > next, which we can give examples of. Plus that could remain the
> > responsibility of the main platform maintainers, who are doing the
> tagging.
> >
> > Braden
> >
> >
> > On Thu, Jan 24, 2013 at 2:56 PM, Jesse <pu...@gmail.com> wrote:
> >
> > > On Thu, Jan 24, 2013 at 11:09 AM, Braden Shepherdson <
> > braden@chromium.org
> > > >wrote:
> > >
> > > > The founding goal we're trying to accomplish here is that we don't
> want
> > > > everyone sitting on changes to be in the next version while we use
> > master
> > > > to prep a release.
> > > >
> > > > I don't think having one branch for prepping the release and another
> > for
> > > > main development is a lot of bureaucracy.
> > > >
> > >
> > > It is not, the 'branch must be named x' is mainly where I have
> concerns.
> > > Really I just want things simple.
> > >
> > >
> > > >
> > > >
> > > > On Thu, Jan 24, 2013 at 1:57 PM, Jesse MacFadyen <
> > > purplecabbage@gmail.com
> > > > >wrote:
> > > >
> > > > > I have been quietly listening on this thread, but thought I should
> at
> > > > > least share my opinion.
> > > > >
> > > > > I don't think adding contribution rules helps anyone. Git is
> > > > > complicated enough as it is, and this just all seems like
> > bureaucracy.
> > > > >
> > > > > I think master should always contain the latest stable code, and be
> > > > > periodically tagged with rc's and versions.
> > > > > All work should be done in personal forks and feature branches.
> > > > > If the latest tag of master is an rc, then we should only be
> merging
> > > > > bugfixes, until the release.
> > > > > Immediately after tagging a version we decide which feature
> branches
> > > > > and pull requests to pull in, and go for it.
> > > > >
> > > > > I don't think this is much different from what we have, but I think
> > > > > that is good.
> > > > > The suggestions thus far, while interesting, don't increase our
> > > > > velocity in my opinion. Also, I can also pretty much guaranty I'll
> > > > > screw it up for the next 3-4 versions. ( because I'm dumb )
> > > > >
> > > > > Cheers,
> > > > > Jesse
> > > > >
> > > > >
> > > > >
> > > > > On 2013-01-24, at 5:53 AM, Andrew Grieve <ag...@chromium.org>
> > wrote:
> > > > >
> > > > > On Wed, Jan 23, 2013 at 4:58 PM, Michael Brooks <
> > > > michael@michaelbrooks.ca
> > > > > >wrote:
> > > > >
> > > > > > Before we move forward, I have a few questions about the "no
> > master"
> > > > > > approach.
> > > > > >
> > > > > > There is *no* master branch, so that community-driven pull
> requests
> > > > will
> > > > > be
> > > > > >> forced to think about which branch to request against.
> > > > > >
> > > > > >
> > > > > > - Andrew, can you cite other projects that do not use a master
> > > branch?
> > > > > This project is my first time using git / github, so I don't have
> > much
> > > to
> > > > > draw from. I was going off of others' suggestions on this thread
> > when I
> > > > > proposed the names.
> > > > >
> > > > >
> > > > > > - On Github, you must have a default branch. If not master, it
> must
> > > be
> > > > > > something else. So, users are not forced to think about the
> branch
> > to
> > > > > send
> > > > > > a pull request again... they will likely just use the default.
> > > > >
> > > > > Hmm, good point. The goal is to get people downloading Cordova for
> > use
> > > to
> > > > > end up with Stable, and for developers to send pull requests
> against
> > > dev.
> > > > > With a forced default branch, I don't think we can accomplish this.
> > > > >
> > > > >
> > > > > >
> > > > > > - Why is the "stable" branch not just "master"?
> > > > >
> > > > > My thinking was that it's not obvious whether Master == bleeding
> > edge,
> > > or
> > > > > Master == Stable version. Using the names "dev" and "stable" makes
> > it a
> > > > bit
> > > > > clear.
> > > > >
> > > > >
> > > > >
> > > > > So... If github forces us to have a default branch, I'm thinking
> that
> > > > > having users send pull requests against "dev" is more valuable than
> > > > having
> > > > > people download the latest "stable" by default. If people are
> pulling
> > > > code
> > > > > from github rather than from our release .zip files, then it's
> likely
> > > > they
> > > > > want to hack on it anyways, or that they want the dev version to
> see
> > if
> > > > > bugs are fixed.
> > > > >
> > > > > Soo.... Here's version #3! If anyone can think of how to keep the
> > three
> > > > > branches while addressing being forced to have a default branch,
> feel
> > > > free
> > > > > to speak up! :)
> > > > >
> > > > >
> > > > > Cordova repositories have two main branches:
> > > > > 1. master
> > > > > 2. next
> > > > >
> > > > > Topic branches exist for collaborating on features, or for
> > code-review
> > > > > purposes.
> > > > >
> > > > > Cordova uses tags to label releases.
> > > > > - Each release candidate has a tag. e.g. "2.2.0rc1"
> > > > > - Each release has a tag. e.g. "2.2.0"
> > > > > - The "latest" tag points to the last stable release (this follows
> > npm
> > > > > conventions)
> > > > >
> > > > >
> > > > > 1. The "next" branch.
> > > > > - This branch is used only when in the process of doing a release.
> > > > > - All tags are created from this branch.
> > > > > - All release-candidate bug-fixes are done on this branch.
> > > > >
> > > > > 2. The "master" branch.
> > > > > - When not in the release-process, all commits are made here
> > > > > - When in the release-process, all non-bugfix commits are made
> here
> > > > > - This is where topic-branches are merged into.
> > > > >
> > > > > Cutting a release:
> > > > > 1. git checkout next && git merge --ff-only master
> > > > > 2. Test test test!
> > > > > 3. Fix bugs by committing them directly to "next" and then doing a
> > > non-ff
> > > > > merge of next into master
> > > > > 4. Tag release candidate
> > > > > 5. Repeat steps 2-4 as necessary
> > > > > 6. Tag the release (both by version and by updating the "latest"
> tag)
> > > > > 7. Create distribution .zip file
> > > > > 8. Test one last time using the dist files
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > >
> > > > > > Thanks,
> > > > > > Michael
> > > > > >
> > > > > > On Wed, Jan 23, 2013 at 11:25 AM, Brian LeRoux <b...@brian.io>
> wrote:
> > > > > >
> > > > > >> I'm liking it. Start in 2.5?
> > > > > >>
> > > > > >> On Wed, Jan 23, 2013 at 1:19 PM, Filip Maj <fi...@adobe.com>
> wrote:
> > > > > >>> Looks great Andrew!
> > > > > >>>
> > > > > >>> If everyone's on board, how are we going to test run this?
> Flip a
> > > > > > switch
> > > > > >>> at a certain point, give it a shot with one repo for one RC?
> > > > > >>>
> > > > > >>> On 1/22/13 12:29 PM, "Andrew Grieve" <ag...@chromium.org>
> > wrote:
> > > > > >>>
> > > > > >>>> Braden, you're right. I've now done some local playing around
> in
> > > > git,
> > > > > > and
> > > > > >>>> have an updated proposal that uses merges instead of deleting
> > > > > branches.
> > > > > >>>> PTAL:
> > > > > >>>>
> > > > > >>>> Cordova repositories have three main branches:
> > > > > >>>> 1. stable
> > > > > >>>> 2. next
> > > > > >>>> 3. dev
> > > > > >>>>
> > > > > >>>> Topic branches also exist for collaborating on features, or
> for
> > > > > >>>> code-review
> > > > > >>>> purposes.
> > > > > >>>>
> > > > > >>>> There is *no* master branch, so that community-driven pull
> > > requests
> > > > > > will
> > > > > >>>> be
> > > > > >>>> forced to think about which branch to request against.
> > > > > >>>>
> > > > > >>>> 1. The "stable" branch.
> > > > > >>>> - Sits at the latest stable release of cordova
> > > > > >>>> - This changes only when doing fast-forward merges from "next"
> > > > > >>>>
> > > > > >>>> 2. The "next" branch.
> > > > > >>>> - This branch is used only when in the process of doing a
> > release.
> > > > > >>>> - All tags (both stable and RC) are done on this branch.
> > > > > >>>> - All release-candidate bug-fixes are done on this branch.
> > > > > >>>>
> > > > > >>>> 3. The "dev" branch.
> > > > > >>>> - This is where non-release-candidate commits are done
> > > > > >>>> - This is where topic-branches are merged into.
> > > > > >>>>
> > > > > >>>> Cutting a release:
> > > > > >>>> 1. git checkout next && git merge --ff-only dev
> > > > > >>>> 2. Test test test!
> > > > > >>>> 3. Fix bugs by committing them directly to "next" and then
> > doing a
> > > > > > non-ff
> > > > > >>>> merge of next into dev
> > > > > >>>> 4. Tag release candidate
> > > > > >>>> 5. Repeat steps 2-4 as necessary
> > > > > >>>> 6. Tag the release
> > > > > >>>> 7. Create distribution .zip file
> > > > > >>>> 8. Test one last time using the dist files
> > > > > >>>> 9. git checkout stable && git merge --ff-only next
> > > > > >>>>
> > > > > >>>>
> > > > > >>>>
> > > > > >>>> On Tue, Jan 22, 2013 at 1:59 PM, Braden Shepherdson
> > > > > >>>> <br...@chromium.org>wrote:
> > > > > >>>>
> > > > > >>>>> I think deleting and recreating branches with the same name
> can
> > > > cause
> > > > > >>>>> badness in git[1] because of remotes. It's not really the
> same
> > > > branch
> > > > > >> in
> > > > > >>>>> terms of commits, and git thinks that your old stable and the
> > new
> > > > > >> stable
> > > > > >>>>> differ by all of each of their commits. Tags can be moved
> > > > > > arbitrarily,
> > > > > >>>>> so I
> > > > > >>>>> think stable makes sense as a tag. I'm not sure about how
> best
> > to
> > > > > >> handle
> > > > > >>>>> next.
> > > > > >>>>>
> > > > > >>>>> [1]
> > > > > >
> > > > >
> > > >
> > >
> >
> http://stackoverflow.com/questions/11844581/git-delete-and-recreate-branc
> > > > > >>>>> h
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>> On Tue, Jan 22, 2013 at 11:31 AM, Andrew Grieve <
> > > > > > agrieve@chromium.org
> > > > > >>>>>> wrote:
> > > > > >>>>>
> > > > > >>>>>> Michal's attending hackathons for the week, and I'm not sure
> > we
> > > > > > need
> > > > > >>>>> to
> > > > > >>>>> do
> > > > > >>>>>> a hang-out for this, as I think we really are quite close to
> > > > > >> resolving
> > > > > >>>>>> this. I'd really like to resolve this ASAP so that we don't
> > need
> > > > to
> > > > > >>>>> have
> > > > > >>>>> a
> > > > > >>>>>> code-freeze for this release.
> > > > > >>>>>>
> > > > > >>>>>> Here's a proposal:
> > > > > >>>>>>
> > > > > >>>>>> Cordova repositories have three main branches:
> > > > > >>>>>> 1. stable
> > > > > >>>>>> 2. next
> > > > > >>>>>> 3. dev
> > > > > >>>>>>
> > > > > >>>>>> Topic branches also exist for collaborating on features, or
> > for
> > > > > >>>>> code-review
> > > > > >>>>>> purposes.
> > > > > >>>>>>
> > > > > >>>>>> There is *no* master branch, so that community-driven pull
> > > > requests
> > > > > >>>>> will
> > > > > >>>>> be
> > > > > >>>>>> forced to think about which branch to request against.
> > > > > >>>>>>
> > > > > >>>>>> 1. The "stable" branch.
> > > > > >>>>>> - Sits at the latest stable release of cordova
> > > > > >>>>>> - No one ever commits to the "stable" branch. It exists only
> > as
> > > a
> > > > > >>>>>> short-cut for checking out the latest stable tag.
> > > > > >>>>>>
> > > > > >>>>>> 2. The "next" branch.
> > > > > >>>>>> - This branch exists only when in the process of doing a
> > > release.
> > > > > >>>>>> - All tags (both stable and RC) are done on this branch.
> > > > > >>>>>> - When a stable tag is done:
> > > > > >>>>>> - The existing "stable" branch is deleted
> > > > > >>>>>> - A new "stable" branch is created from "next".
> > > > > >>>>>> - The "next" branch is deleted.
> > > > > >>>>>>
> > > > > >>>>>> 3. The "dev" branch.
> > > > > >>>>>> - This is where all commits are done
> > > > > >>>>>> - This is where topic-branches are merged into.
> > > > > >>>>>>
> > > > > >>>>>> Cutting a release:
> > > > > >>>>>> 1. Create "next" from the HEAD of "dev"
> > > > > >>>>>> 2. Test test test!
> > > > > >>>>>> 3. Fix bugs by committing them to "dev" and then
> > cherry-picking
> > > > > > them
> > > > > >>>>> into
> > > > > >>>>>> "next"
> > > > > >>>>>> 4. Tag release candidate
> > > > > >>>>>> 5. Repeat steps 2-4 as necessary
> > > > > >>>>>> 6. Tag the release
> > > > > >>>>>> 7. Create distribution .zip file
> > > > > >>>>>> 8. Test one last time using the dist files
> > > > > >>>>>> 9. Delete "stable"
> > > > > >>>>>> 10. Create a new "stable" by branching from the HEAD of
> "next"
> > > > > >>>>>> 11. Delete the "next" branch
> > > > > >>>>>>
> > > > > >>>>>>
> > > > > >>>>>>
> > > > > >>>>>> On Wed, Jan 16, 2013 at 10:34 AM, Michal Mocny <
> > > > > > mmocny@chromium.org>
> > > > > >>>>>> wrote:
> > > > > >>>>>>
> > > > > >>>>>>> Just going to throw out one of my personal requirements for
> > > > > >> whatever
> > > > > >>>>>>> proposal we come up with, so it doesn't get lost:
> > > > > >>>>>>>
> > > > > >>>>>>> * Feature branches are great for feature work and/or large
> > > > > > sweeping
> > > > > >>>>>>> changes, as are JIRA bugs for tracking them, but cordova
> has
> > > many
> > > > > >>>>> many
> > > > > >>>>>>> trivial issues that could be fixed with "drive-by" patches
> > that
> > > > > >>>>> require
> > > > > >>>>>> as
> > > > > >>>>>>> little friction to commit as possible.
> > > > > >>>>>>>
> > > > > >>>>>>>
> > > > > >>>>>>> On Tue, Jan 15, 2013 at 3:05 PM, Marcel Kinard <
> > > > > > cmarcelk@gmail.com
> > > > > >>>
> > > > > >>>>>> wrote:
> > > > > >>>>>>>
> > > > > >>>>>>>> How about if there is a specific straw man proposal at the
> > > > > >>>>> beginning
> > > > > >>>>> of
> > > > > >>>>>>>> the face-time? Then the folks that are in agreement won't
> > need
> > > > > > to
> > > > > >>>>> say
> > > > > >>>>>>>> anything ;-)
> > > > > >>>>>>>>
> > > > > >>>>>>>> Seriously, making adjustments to something tangible is
> > easier
> > > > > >> than
> > > > > >>>>>>>> instantiating it from scratch. A volunteer for a very
> simple
> > > > > >>>>> writeup
> > > > > >>>>> on
> > > > > >>>>>>> the
> > > > > >>>>>>>> wiki?
> > > > > >>>>>>>>
> > > > > >>>>>>>> -- Marcel Kinard
> > > > > >>>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>>>> On 1/14/2013 10:06 PM, Michal Mocny wrote:
> > > > > >>>>>>>>
> > > > > >>>>>>>>> Okay gentlemen, I think there have been countless good
> > points
> > > > > >>>>> made
> > > > > >>>>>> from
> > > > > >>>>>>>>> all
> > > > > >>>>>>>>> parties, but also some bike-shedding.
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> Perhaps it is time to schedule some face-time to better
> > > > > >>>>> articulate
> > > > > >>>>>> some
> > > > > >>>>>>> of
> > > > > >>>>>>>>> the finer points, and to help come to some consensus?
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> -Michal
> > > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > @purplecabbage
> > > risingj.com
> > >
> >
>
--
@purplecabbage
risingj.com
Re: too long to package a release?
Posted by Andrew Grieve <ag...@chromium.org>.
Just to clarify - there should be *no* using of the git cherry-picking
command, only git merge.
Jesse - not sure what you're referring to with "branch must be named x".
The latest revision of the proposal has only two branches: master and next.
Do you mean you don't like the name "next"?
Maybe the proposal will seem simpler if put in the form of code :)
if (!inReleaseMode) {
commitToBranch('master');
} else {
if (isBugFix) {
commitToBranch('next');
mergeBranch('next').into('master');
} else {
commitToBranch('master');
}
}
On Thu, Jan 24, 2013 at 3:06 PM, Braden Shepherdson <br...@chromium.org>wrote:
> Most of the time the flow will be unchanged: push to master. Tagging things
> we already know how to do; that doesn't change.
>
> The only new flow for most people is cherrypicking bug fixes from master to
> next, which we can give examples of. Plus that could remain the
> responsibility of the main platform maintainers, who are doing the tagging.
>
> Braden
>
>
> On Thu, Jan 24, 2013 at 2:56 PM, Jesse <pu...@gmail.com> wrote:
>
> > On Thu, Jan 24, 2013 at 11:09 AM, Braden Shepherdson <
> braden@chromium.org
> > >wrote:
> >
> > > The founding goal we're trying to accomplish here is that we don't want
> > > everyone sitting on changes to be in the next version while we use
> master
> > > to prep a release.
> > >
> > > I don't think having one branch for prepping the release and another
> for
> > > main development is a lot of bureaucracy.
> > >
> >
> > It is not, the 'branch must be named x' is mainly where I have concerns.
> > Really I just want things simple.
> >
> >
> > >
> > >
> > > On Thu, Jan 24, 2013 at 1:57 PM, Jesse MacFadyen <
> > purplecabbage@gmail.com
> > > >wrote:
> > >
> > > > I have been quietly listening on this thread, but thought I should at
> > > > least share my opinion.
> > > >
> > > > I don't think adding contribution rules helps anyone. Git is
> > > > complicated enough as it is, and this just all seems like
> bureaucracy.
> > > >
> > > > I think master should always contain the latest stable code, and be
> > > > periodically tagged with rc's and versions.
> > > > All work should be done in personal forks and feature branches.
> > > > If the latest tag of master is an rc, then we should only be merging
> > > > bugfixes, until the release.
> > > > Immediately after tagging a version we decide which feature branches
> > > > and pull requests to pull in, and go for it.
> > > >
> > > > I don't think this is much different from what we have, but I think
> > > > that is good.
> > > > The suggestions thus far, while interesting, don't increase our
> > > > velocity in my opinion. Also, I can also pretty much guaranty I'll
> > > > screw it up for the next 3-4 versions. ( because I'm dumb )
> > > >
> > > > Cheers,
> > > > Jesse
> > > >
> > > >
> > > >
> > > > On 2013-01-24, at 5:53 AM, Andrew Grieve <ag...@chromium.org>
> wrote:
> > > >
> > > > On Wed, Jan 23, 2013 at 4:58 PM, Michael Brooks <
> > > michael@michaelbrooks.ca
> > > > >wrote:
> > > >
> > > > > Before we move forward, I have a few questions about the "no
> master"
> > > > > approach.
> > > > >
> > > > > There is *no* master branch, so that community-driven pull requests
> > > will
> > > > be
> > > > >> forced to think about which branch to request against.
> > > > >
> > > > >
> > > > > - Andrew, can you cite other projects that do not use a master
> > branch?
> > > > This project is my first time using git / github, so I don't have
> much
> > to
> > > > draw from. I was going off of others' suggestions on this thread
> when I
> > > > proposed the names.
> > > >
> > > >
> > > > > - On Github, you must have a default branch. If not master, it must
> > be
> > > > > something else. So, users are not forced to think about the branch
> to
> > > > send
> > > > > a pull request again... they will likely just use the default.
> > > >
> > > > Hmm, good point. The goal is to get people downloading Cordova for
> use
> > to
> > > > end up with Stable, and for developers to send pull requests against
> > dev.
> > > > With a forced default branch, I don't think we can accomplish this.
> > > >
> > > >
> > > > >
> > > > > - Why is the "stable" branch not just "master"?
> > > >
> > > > My thinking was that it's not obvious whether Master == bleeding
> edge,
> > or
> > > > Master == Stable version. Using the names "dev" and "stable" makes
> it a
> > > bit
> > > > clear.
> > > >
> > > >
> > > >
> > > > So... If github forces us to have a default branch, I'm thinking that
> > > > having users send pull requests against "dev" is more valuable than
> > > having
> > > > people download the latest "stable" by default. If people are pulling
> > > code
> > > > from github rather than from our release .zip files, then it's likely
> > > they
> > > > want to hack on it anyways, or that they want the dev version to see
> if
> > > > bugs are fixed.
> > > >
> > > > Soo.... Here's version #3! If anyone can think of how to keep the
> three
> > > > branches while addressing being forced to have a default branch, feel
> > > free
> > > > to speak up! :)
> > > >
> > > >
> > > > Cordova repositories have two main branches:
> > > > 1. master
> > > > 2. next
> > > >
> > > > Topic branches exist for collaborating on features, or for
> code-review
> > > > purposes.
> > > >
> > > > Cordova uses tags to label releases.
> > > > - Each release candidate has a tag. e.g. "2.2.0rc1"
> > > > - Each release has a tag. e.g. "2.2.0"
> > > > - The "latest" tag points to the last stable release (this follows
> npm
> > > > conventions)
> > > >
> > > >
> > > > 1. The "next" branch.
> > > > - This branch is used only when in the process of doing a release.
> > > > - All tags are created from this branch.
> > > > - All release-candidate bug-fixes are done on this branch.
> > > >
> > > > 2. The "master" branch.
> > > > - When not in the release-process, all commits are made here
> > > > - When in the release-process, all non-bugfix commits are made here
> > > > - This is where topic-branches are merged into.
> > > >
> > > > Cutting a release:
> > > > 1. git checkout next && git merge --ff-only master
> > > > 2. Test test test!
> > > > 3. Fix bugs by committing them directly to "next" and then doing a
> > non-ff
> > > > merge of next into master
> > > > 4. Tag release candidate
> > > > 5. Repeat steps 2-4 as necessary
> > > > 6. Tag the release (both by version and by updating the "latest" tag)
> > > > 7. Create distribution .zip file
> > > > 8. Test one last time using the dist files
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > >
> > > > > Thanks,
> > > > > Michael
> > > > >
> > > > > On Wed, Jan 23, 2013 at 11:25 AM, Brian LeRoux <b...@brian.io> wrote:
> > > > >
> > > > >> I'm liking it. Start in 2.5?
> > > > >>
> > > > >> On Wed, Jan 23, 2013 at 1:19 PM, Filip Maj <fi...@adobe.com> wrote:
> > > > >>> Looks great Andrew!
> > > > >>>
> > > > >>> If everyone's on board, how are we going to test run this? Flip a
> > > > > switch
> > > > >>> at a certain point, give it a shot with one repo for one RC?
> > > > >>>
> > > > >>> On 1/22/13 12:29 PM, "Andrew Grieve" <ag...@chromium.org>
> wrote:
> > > > >>>
> > > > >>>> Braden, you're right. I've now done some local playing around in
> > > git,
> > > > > and
> > > > >>>> have an updated proposal that uses merges instead of deleting
> > > > branches.
> > > > >>>> PTAL:
> > > > >>>>
> > > > >>>> Cordova repositories have three main branches:
> > > > >>>> 1. stable
> > > > >>>> 2. next
> > > > >>>> 3. dev
> > > > >>>>
> > > > >>>> Topic branches also exist for collaborating on features, or for
> > > > >>>> code-review
> > > > >>>> purposes.
> > > > >>>>
> > > > >>>> There is *no* master branch, so that community-driven pull
> > requests
> > > > > will
> > > > >>>> be
> > > > >>>> forced to think about which branch to request against.
> > > > >>>>
> > > > >>>> 1. The "stable" branch.
> > > > >>>> - Sits at the latest stable release of cordova
> > > > >>>> - This changes only when doing fast-forward merges from "next"
> > > > >>>>
> > > > >>>> 2. The "next" branch.
> > > > >>>> - This branch is used only when in the process of doing a
> release.
> > > > >>>> - All tags (both stable and RC) are done on this branch.
> > > > >>>> - All release-candidate bug-fixes are done on this branch.
> > > > >>>>
> > > > >>>> 3. The "dev" branch.
> > > > >>>> - This is where non-release-candidate commits are done
> > > > >>>> - This is where topic-branches are merged into.
> > > > >>>>
> > > > >>>> Cutting a release:
> > > > >>>> 1. git checkout next && git merge --ff-only dev
> > > > >>>> 2. Test test test!
> > > > >>>> 3. Fix bugs by committing them directly to "next" and then
> doing a
> > > > > non-ff
> > > > >>>> merge of next into dev
> > > > >>>> 4. Tag release candidate
> > > > >>>> 5. Repeat steps 2-4 as necessary
> > > > >>>> 6. Tag the release
> > > > >>>> 7. Create distribution .zip file
> > > > >>>> 8. Test one last time using the dist files
> > > > >>>> 9. git checkout stable && git merge --ff-only next
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>> On Tue, Jan 22, 2013 at 1:59 PM, Braden Shepherdson
> > > > >>>> <br...@chromium.org>wrote:
> > > > >>>>
> > > > >>>>> I think deleting and recreating branches with the same name can
> > > cause
> > > > >>>>> badness in git[1] because of remotes. It's not really the same
> > > branch
> > > > >> in
> > > > >>>>> terms of commits, and git thinks that your old stable and the
> new
> > > > >> stable
> > > > >>>>> differ by all of each of their commits. Tags can be moved
> > > > > arbitrarily,
> > > > >>>>> so I
> > > > >>>>> think stable makes sense as a tag. I'm not sure about how best
> to
> > > > >> handle
> > > > >>>>> next.
> > > > >>>>>
> > > > >>>>> [1]
> > > > >
> > > >
> > >
> >
> http://stackoverflow.com/questions/11844581/git-delete-and-recreate-branc
> > > > >>>>> h
> > > > >>>>>
> > > > >>>>>
> > > > >>>>> On Tue, Jan 22, 2013 at 11:31 AM, Andrew Grieve <
> > > > > agrieve@chromium.org
> > > > >>>>>> wrote:
> > > > >>>>>
> > > > >>>>>> Michal's attending hackathons for the week, and I'm not sure
> we
> > > > > need
> > > > >>>>> to
> > > > >>>>> do
> > > > >>>>>> a hang-out for this, as I think we really are quite close to
> > > > >> resolving
> > > > >>>>>> this. I'd really like to resolve this ASAP so that we don't
> need
> > > to
> > > > >>>>> have
> > > > >>>>> a
> > > > >>>>>> code-freeze for this release.
> > > > >>>>>>
> > > > >>>>>> Here's a proposal:
> > > > >>>>>>
> > > > >>>>>> Cordova repositories have three main branches:
> > > > >>>>>> 1. stable
> > > > >>>>>> 2. next
> > > > >>>>>> 3. dev
> > > > >>>>>>
> > > > >>>>>> Topic branches also exist for collaborating on features, or
> for
> > > > >>>>> code-review
> > > > >>>>>> purposes.
> > > > >>>>>>
> > > > >>>>>> There is *no* master branch, so that community-driven pull
> > > requests
> > > > >>>>> will
> > > > >>>>> be
> > > > >>>>>> forced to think about which branch to request against.
> > > > >>>>>>
> > > > >>>>>> 1. The "stable" branch.
> > > > >>>>>> - Sits at the latest stable release of cordova
> > > > >>>>>> - No one ever commits to the "stable" branch. It exists only
> as
> > a
> > > > >>>>>> short-cut for checking out the latest stable tag.
> > > > >>>>>>
> > > > >>>>>> 2. The "next" branch.
> > > > >>>>>> - This branch exists only when in the process of doing a
> > release.
> > > > >>>>>> - All tags (both stable and RC) are done on this branch.
> > > > >>>>>> - When a stable tag is done:
> > > > >>>>>> - The existing "stable" branch is deleted
> > > > >>>>>> - A new "stable" branch is created from "next".
> > > > >>>>>> - The "next" branch is deleted.
> > > > >>>>>>
> > > > >>>>>> 3. The "dev" branch.
> > > > >>>>>> - This is where all commits are done
> > > > >>>>>> - This is where topic-branches are merged into.
> > > > >>>>>>
> > > > >>>>>> Cutting a release:
> > > > >>>>>> 1. Create "next" from the HEAD of "dev"
> > > > >>>>>> 2. Test test test!
> > > > >>>>>> 3. Fix bugs by committing them to "dev" and then
> cherry-picking
> > > > > them
> > > > >>>>> into
> > > > >>>>>> "next"
> > > > >>>>>> 4. Tag release candidate
> > > > >>>>>> 5. Repeat steps 2-4 as necessary
> > > > >>>>>> 6. Tag the release
> > > > >>>>>> 7. Create distribution .zip file
> > > > >>>>>> 8. Test one last time using the dist files
> > > > >>>>>> 9. Delete "stable"
> > > > >>>>>> 10. Create a new "stable" by branching from the HEAD of "next"
> > > > >>>>>> 11. Delete the "next" branch
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>> On Wed, Jan 16, 2013 at 10:34 AM, Michal Mocny <
> > > > > mmocny@chromium.org>
> > > > >>>>>> wrote:
> > > > >>>>>>
> > > > >>>>>>> Just going to throw out one of my personal requirements for
> > > > >> whatever
> > > > >>>>>>> proposal we come up with, so it doesn't get lost:
> > > > >>>>>>>
> > > > >>>>>>> * Feature branches are great for feature work and/or large
> > > > > sweeping
> > > > >>>>>>> changes, as are JIRA bugs for tracking them, but cordova has
> > many
> > > > >>>>> many
> > > > >>>>>>> trivial issues that could be fixed with "drive-by" patches
> that
> > > > >>>>> require
> > > > >>>>>> as
> > > > >>>>>>> little friction to commit as possible.
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>> On Tue, Jan 15, 2013 at 3:05 PM, Marcel Kinard <
> > > > > cmarcelk@gmail.com
> > > > >>>
> > > > >>>>>> wrote:
> > > > >>>>>>>
> > > > >>>>>>>> How about if there is a specific straw man proposal at the
> > > > >>>>> beginning
> > > > >>>>> of
> > > > >>>>>>>> the face-time? Then the folks that are in agreement won't
> need
> > > > > to
> > > > >>>>> say
> > > > >>>>>>>> anything ;-)
> > > > >>>>>>>>
> > > > >>>>>>>> Seriously, making adjustments to something tangible is
> easier
> > > > >> than
> > > > >>>>>>>> instantiating it from scratch. A volunteer for a very simple
> > > > >>>>> writeup
> > > > >>>>> on
> > > > >>>>>>> the
> > > > >>>>>>>> wiki?
> > > > >>>>>>>>
> > > > >>>>>>>> -- Marcel Kinard
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>> On 1/14/2013 10:06 PM, Michal Mocny wrote:
> > > > >>>>>>>>
> > > > >>>>>>>>> Okay gentlemen, I think there have been countless good
> points
> > > > >>>>> made
> > > > >>>>>> from
> > > > >>>>>>>>> all
> > > > >>>>>>>>> parties, but also some bike-shedding.
> > > > >>>>>>>>>
> > > > >>>>>>>>> Perhaps it is time to schedule some face-time to better
> > > > >>>>> articulate
> > > > >>>>>> some
> > > > >>>>>>> of
> > > > >>>>>>>>> the finer points, and to help come to some consensus?
> > > > >>>>>>>>>
> > > > >>>>>>>>> -Michal
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > @purplecabbage
> > risingj.com
> >
>
Re: too long to package a release?
Posted by Braden Shepherdson <br...@chromium.org>.
Most of the time the flow will be unchanged: push to master. Tagging things
we already know how to do; that doesn't change.
The only new flow for most people is cherrypicking bug fixes from master to
next, which we can give examples of. Plus that could remain the
responsibility of the main platform maintainers, who are doing the tagging.
Braden
On Thu, Jan 24, 2013 at 2:56 PM, Jesse <pu...@gmail.com> wrote:
> On Thu, Jan 24, 2013 at 11:09 AM, Braden Shepherdson <braden@chromium.org
> >wrote:
>
> > The founding goal we're trying to accomplish here is that we don't want
> > everyone sitting on changes to be in the next version while we use master
> > to prep a release.
> >
> > I don't think having one branch for prepping the release and another for
> > main development is a lot of bureaucracy.
> >
>
> It is not, the 'branch must be named x' is mainly where I have concerns.
> Really I just want things simple.
>
>
> >
> >
> > On Thu, Jan 24, 2013 at 1:57 PM, Jesse MacFadyen <
> purplecabbage@gmail.com
> > >wrote:
> >
> > > I have been quietly listening on this thread, but thought I should at
> > > least share my opinion.
> > >
> > > I don't think adding contribution rules helps anyone. Git is
> > > complicated enough as it is, and this just all seems like bureaucracy.
> > >
> > > I think master should always contain the latest stable code, and be
> > > periodically tagged with rc's and versions.
> > > All work should be done in personal forks and feature branches.
> > > If the latest tag of master is an rc, then we should only be merging
> > > bugfixes, until the release.
> > > Immediately after tagging a version we decide which feature branches
> > > and pull requests to pull in, and go for it.
> > >
> > > I don't think this is much different from what we have, but I think
> > > that is good.
> > > The suggestions thus far, while interesting, don't increase our
> > > velocity in my opinion. Also, I can also pretty much guaranty I'll
> > > screw it up for the next 3-4 versions. ( because I'm dumb )
> > >
> > > Cheers,
> > > Jesse
> > >
> > >
> > >
> > > On 2013-01-24, at 5:53 AM, Andrew Grieve <ag...@chromium.org> wrote:
> > >
> > > On Wed, Jan 23, 2013 at 4:58 PM, Michael Brooks <
> > michael@michaelbrooks.ca
> > > >wrote:
> > >
> > > > Before we move forward, I have a few questions about the "no master"
> > > > approach.
> > > >
> > > > There is *no* master branch, so that community-driven pull requests
> > will
> > > be
> > > >> forced to think about which branch to request against.
> > > >
> > > >
> > > > - Andrew, can you cite other projects that do not use a master
> branch?
> > > This project is my first time using git / github, so I don't have much
> to
> > > draw from. I was going off of others' suggestions on this thread when I
> > > proposed the names.
> > >
> > >
> > > > - On Github, you must have a default branch. If not master, it must
> be
> > > > something else. So, users are not forced to think about the branch to
> > > send
> > > > a pull request again... they will likely just use the default.
> > >
> > > Hmm, good point. The goal is to get people downloading Cordova for use
> to
> > > end up with Stable, and for developers to send pull requests against
> dev.
> > > With a forced default branch, I don't think we can accomplish this.
> > >
> > >
> > > >
> > > > - Why is the "stable" branch not just "master"?
> > >
> > > My thinking was that it's not obvious whether Master == bleeding edge,
> or
> > > Master == Stable version. Using the names "dev" and "stable" makes it a
> > bit
> > > clear.
> > >
> > >
> > >
> > > So... If github forces us to have a default branch, I'm thinking that
> > > having users send pull requests against "dev" is more valuable than
> > having
> > > people download the latest "stable" by default. If people are pulling
> > code
> > > from github rather than from our release .zip files, then it's likely
> > they
> > > want to hack on it anyways, or that they want the dev version to see if
> > > bugs are fixed.
> > >
> > > Soo.... Here's version #3! If anyone can think of how to keep the three
> > > branches while addressing being forced to have a default branch, feel
> > free
> > > to speak up! :)
> > >
> > >
> > > Cordova repositories have two main branches:
> > > 1. master
> > > 2. next
> > >
> > > Topic branches exist for collaborating on features, or for code-review
> > > purposes.
> > >
> > > Cordova uses tags to label releases.
> > > - Each release candidate has a tag. e.g. "2.2.0rc1"
> > > - Each release has a tag. e.g. "2.2.0"
> > > - The "latest" tag points to the last stable release (this follows npm
> > > conventions)
> > >
> > >
> > > 1. The "next" branch.
> > > - This branch is used only when in the process of doing a release.
> > > - All tags are created from this branch.
> > > - All release-candidate bug-fixes are done on this branch.
> > >
> > > 2. The "master" branch.
> > > - When not in the release-process, all commits are made here
> > > - When in the release-process, all non-bugfix commits are made here
> > > - This is where topic-branches are merged into.
> > >
> > > Cutting a release:
> > > 1. git checkout next && git merge --ff-only master
> > > 2. Test test test!
> > > 3. Fix bugs by committing them directly to "next" and then doing a
> non-ff
> > > merge of next into master
> > > 4. Tag release candidate
> > > 5. Repeat steps 2-4 as necessary
> > > 6. Tag the release (both by version and by updating the "latest" tag)
> > > 7. Create distribution .zip file
> > > 8. Test one last time using the dist files
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > >
> > > > Thanks,
> > > > Michael
> > > >
> > > > On Wed, Jan 23, 2013 at 11:25 AM, Brian LeRoux <b...@brian.io> wrote:
> > > >
> > > >> I'm liking it. Start in 2.5?
> > > >>
> > > >> On Wed, Jan 23, 2013 at 1:19 PM, Filip Maj <fi...@adobe.com> wrote:
> > > >>> Looks great Andrew!
> > > >>>
> > > >>> If everyone's on board, how are we going to test run this? Flip a
> > > > switch
> > > >>> at a certain point, give it a shot with one repo for one RC?
> > > >>>
> > > >>> On 1/22/13 12:29 PM, "Andrew Grieve" <ag...@chromium.org> wrote:
> > > >>>
> > > >>>> Braden, you're right. I've now done some local playing around in
> > git,
> > > > and
> > > >>>> have an updated proposal that uses merges instead of deleting
> > > branches.
> > > >>>> PTAL:
> > > >>>>
> > > >>>> Cordova repositories have three main branches:
> > > >>>> 1. stable
> > > >>>> 2. next
> > > >>>> 3. dev
> > > >>>>
> > > >>>> Topic branches also exist for collaborating on features, or for
> > > >>>> code-review
> > > >>>> purposes.
> > > >>>>
> > > >>>> There is *no* master branch, so that community-driven pull
> requests
> > > > will
> > > >>>> be
> > > >>>> forced to think about which branch to request against.
> > > >>>>
> > > >>>> 1. The "stable" branch.
> > > >>>> - Sits at the latest stable release of cordova
> > > >>>> - This changes only when doing fast-forward merges from "next"
> > > >>>>
> > > >>>> 2. The "next" branch.
> > > >>>> - This branch is used only when in the process of doing a release.
> > > >>>> - All tags (both stable and RC) are done on this branch.
> > > >>>> - All release-candidate bug-fixes are done on this branch.
> > > >>>>
> > > >>>> 3. The "dev" branch.
> > > >>>> - This is where non-release-candidate commits are done
> > > >>>> - This is where topic-branches are merged into.
> > > >>>>
> > > >>>> Cutting a release:
> > > >>>> 1. git checkout next && git merge --ff-only dev
> > > >>>> 2. Test test test!
> > > >>>> 3. Fix bugs by committing them directly to "next" and then doing a
> > > > non-ff
> > > >>>> merge of next into dev
> > > >>>> 4. Tag release candidate
> > > >>>> 5. Repeat steps 2-4 as necessary
> > > >>>> 6. Tag the release
> > > >>>> 7. Create distribution .zip file
> > > >>>> 8. Test one last time using the dist files
> > > >>>> 9. git checkout stable && git merge --ff-only next
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>> On Tue, Jan 22, 2013 at 1:59 PM, Braden Shepherdson
> > > >>>> <br...@chromium.org>wrote:
> > > >>>>
> > > >>>>> I think deleting and recreating branches with the same name can
> > cause
> > > >>>>> badness in git[1] because of remotes. It's not really the same
> > branch
> > > >> in
> > > >>>>> terms of commits, and git thinks that your old stable and the new
> > > >> stable
> > > >>>>> differ by all of each of their commits. Tags can be moved
> > > > arbitrarily,
> > > >>>>> so I
> > > >>>>> think stable makes sense as a tag. I'm not sure about how best to
> > > >> handle
> > > >>>>> next.
> > > >>>>>
> > > >>>>> [1]
> > > >
> > >
> >
> http://stackoverflow.com/questions/11844581/git-delete-and-recreate-branc
> > > >>>>> h
> > > >>>>>
> > > >>>>>
> > > >>>>> On Tue, Jan 22, 2013 at 11:31 AM, Andrew Grieve <
> > > > agrieve@chromium.org
> > > >>>>>> wrote:
> > > >>>>>
> > > >>>>>> Michal's attending hackathons for the week, and I'm not sure we
> > > > need
> > > >>>>> to
> > > >>>>> do
> > > >>>>>> a hang-out for this, as I think we really are quite close to
> > > >> resolving
> > > >>>>>> this. I'd really like to resolve this ASAP so that we don't need
> > to
> > > >>>>> have
> > > >>>>> a
> > > >>>>>> code-freeze for this release.
> > > >>>>>>
> > > >>>>>> Here's a proposal:
> > > >>>>>>
> > > >>>>>> Cordova repositories have three main branches:
> > > >>>>>> 1. stable
> > > >>>>>> 2. next
> > > >>>>>> 3. dev
> > > >>>>>>
> > > >>>>>> Topic branches also exist for collaborating on features, or for
> > > >>>>> code-review
> > > >>>>>> purposes.
> > > >>>>>>
> > > >>>>>> There is *no* master branch, so that community-driven pull
> > requests
> > > >>>>> will
> > > >>>>> be
> > > >>>>>> forced to think about which branch to request against.
> > > >>>>>>
> > > >>>>>> 1. The "stable" branch.
> > > >>>>>> - Sits at the latest stable release of cordova
> > > >>>>>> - No one ever commits to the "stable" branch. It exists only as
> a
> > > >>>>>> short-cut for checking out the latest stable tag.
> > > >>>>>>
> > > >>>>>> 2. The "next" branch.
> > > >>>>>> - This branch exists only when in the process of doing a
> release.
> > > >>>>>> - All tags (both stable and RC) are done on this branch.
> > > >>>>>> - When a stable tag is done:
> > > >>>>>> - The existing "stable" branch is deleted
> > > >>>>>> - A new "stable" branch is created from "next".
> > > >>>>>> - The "next" branch is deleted.
> > > >>>>>>
> > > >>>>>> 3. The "dev" branch.
> > > >>>>>> - This is where all commits are done
> > > >>>>>> - This is where topic-branches are merged into.
> > > >>>>>>
> > > >>>>>> Cutting a release:
> > > >>>>>> 1. Create "next" from the HEAD of "dev"
> > > >>>>>> 2. Test test test!
> > > >>>>>> 3. Fix bugs by committing them to "dev" and then cherry-picking
> > > > them
> > > >>>>> into
> > > >>>>>> "next"
> > > >>>>>> 4. Tag release candidate
> > > >>>>>> 5. Repeat steps 2-4 as necessary
> > > >>>>>> 6. Tag the release
> > > >>>>>> 7. Create distribution .zip file
> > > >>>>>> 8. Test one last time using the dist files
> > > >>>>>> 9. Delete "stable"
> > > >>>>>> 10. Create a new "stable" by branching from the HEAD of "next"
> > > >>>>>> 11. Delete the "next" branch
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> On Wed, Jan 16, 2013 at 10:34 AM, Michal Mocny <
> > > > mmocny@chromium.org>
> > > >>>>>> wrote:
> > > >>>>>>
> > > >>>>>>> Just going to throw out one of my personal requirements for
> > > >> whatever
> > > >>>>>>> proposal we come up with, so it doesn't get lost:
> > > >>>>>>>
> > > >>>>>>> * Feature branches are great for feature work and/or large
> > > > sweeping
> > > >>>>>>> changes, as are JIRA bugs for tracking them, but cordova has
> many
> > > >>>>> many
> > > >>>>>>> trivial issues that could be fixed with "drive-by" patches that
> > > >>>>> require
> > > >>>>>> as
> > > >>>>>>> little friction to commit as possible.
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>> On Tue, Jan 15, 2013 at 3:05 PM, Marcel Kinard <
> > > > cmarcelk@gmail.com
> > > >>>
> > > >>>>>> wrote:
> > > >>>>>>>
> > > >>>>>>>> How about if there is a specific straw man proposal at the
> > > >>>>> beginning
> > > >>>>> of
> > > >>>>>>>> the face-time? Then the folks that are in agreement won't need
> > > > to
> > > >>>>> say
> > > >>>>>>>> anything ;-)
> > > >>>>>>>>
> > > >>>>>>>> Seriously, making adjustments to something tangible is easier
> > > >> than
> > > >>>>>>>> instantiating it from scratch. A volunteer for a very simple
> > > >>>>> writeup
> > > >>>>> on
> > > >>>>>>> the
> > > >>>>>>>> wiki?
> > > >>>>>>>>
> > > >>>>>>>> -- Marcel Kinard
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> On 1/14/2013 10:06 PM, Michal Mocny wrote:
> > > >>>>>>>>
> > > >>>>>>>>> Okay gentlemen, I think there have been countless good points
> > > >>>>> made
> > > >>>>>> from
> > > >>>>>>>>> all
> > > >>>>>>>>> parties, but also some bike-shedding.
> > > >>>>>>>>>
> > > >>>>>>>>> Perhaps it is time to schedule some face-time to better
> > > >>>>> articulate
> > > >>>>>> some
> > > >>>>>>> of
> > > >>>>>>>>> the finer points, and to help come to some consensus?
> > > >>>>>>>>>
> > > >>>>>>>>> -Michal
> > > >
> > >
> >
>
>
>
> --
> @purplecabbage
> risingj.com
>
Re: too long to package a release?
Posted by Jesse <pu...@gmail.com>.
On Thu, Jan 24, 2013 at 11:09 AM, Braden Shepherdson <br...@chromium.org>wrote:
> The founding goal we're trying to accomplish here is that we don't want
> everyone sitting on changes to be in the next version while we use master
> to prep a release.
>
> I don't think having one branch for prepping the release and another for
> main development is a lot of bureaucracy.
>
It is not, the 'branch must be named x' is mainly where I have concerns.
Really I just want things simple.
>
>
> On Thu, Jan 24, 2013 at 1:57 PM, Jesse MacFadyen <purplecabbage@gmail.com
> >wrote:
>
> > I have been quietly listening on this thread, but thought I should at
> > least share my opinion.
> >
> > I don't think adding contribution rules helps anyone. Git is
> > complicated enough as it is, and this just all seems like bureaucracy.
> >
> > I think master should always contain the latest stable code, and be
> > periodically tagged with rc's and versions.
> > All work should be done in personal forks and feature branches.
> > If the latest tag of master is an rc, then we should only be merging
> > bugfixes, until the release.
> > Immediately after tagging a version we decide which feature branches
> > and pull requests to pull in, and go for it.
> >
> > I don't think this is much different from what we have, but I think
> > that is good.
> > The suggestions thus far, while interesting, don't increase our
> > velocity in my opinion. Also, I can also pretty much guaranty I'll
> > screw it up for the next 3-4 versions. ( because I'm dumb )
> >
> > Cheers,
> > Jesse
> >
> >
> >
> > On 2013-01-24, at 5:53 AM, Andrew Grieve <ag...@chromium.org> wrote:
> >
> > On Wed, Jan 23, 2013 at 4:58 PM, Michael Brooks <
> michael@michaelbrooks.ca
> > >wrote:
> >
> > > Before we move forward, I have a few questions about the "no master"
> > > approach.
> > >
> > > There is *no* master branch, so that community-driven pull requests
> will
> > be
> > >> forced to think about which branch to request against.
> > >
> > >
> > > - Andrew, can you cite other projects that do not use a master branch?
> > This project is my first time using git / github, so I don't have much to
> > draw from. I was going off of others' suggestions on this thread when I
> > proposed the names.
> >
> >
> > > - On Github, you must have a default branch. If not master, it must be
> > > something else. So, users are not forced to think about the branch to
> > send
> > > a pull request again... they will likely just use the default.
> >
> > Hmm, good point. The goal is to get people downloading Cordova for use to
> > end up with Stable, and for developers to send pull requests against dev.
> > With a forced default branch, I don't think we can accomplish this.
> >
> >
> > >
> > > - Why is the "stable" branch not just "master"?
> >
> > My thinking was that it's not obvious whether Master == bleeding edge, or
> > Master == Stable version. Using the names "dev" and "stable" makes it a
> bit
> > clear.
> >
> >
> >
> > So... If github forces us to have a default branch, I'm thinking that
> > having users send pull requests against "dev" is more valuable than
> having
> > people download the latest "stable" by default. If people are pulling
> code
> > from github rather than from our release .zip files, then it's likely
> they
> > want to hack on it anyways, or that they want the dev version to see if
> > bugs are fixed.
> >
> > Soo.... Here's version #3! If anyone can think of how to keep the three
> > branches while addressing being forced to have a default branch, feel
> free
> > to speak up! :)
> >
> >
> > Cordova repositories have two main branches:
> > 1. master
> > 2. next
> >
> > Topic branches exist for collaborating on features, or for code-review
> > purposes.
> >
> > Cordova uses tags to label releases.
> > - Each release candidate has a tag. e.g. "2.2.0rc1"
> > - Each release has a tag. e.g. "2.2.0"
> > - The "latest" tag points to the last stable release (this follows npm
> > conventions)
> >
> >
> > 1. The "next" branch.
> > - This branch is used only when in the process of doing a release.
> > - All tags are created from this branch.
> > - All release-candidate bug-fixes are done on this branch.
> >
> > 2. The "master" branch.
> > - When not in the release-process, all commits are made here
> > - When in the release-process, all non-bugfix commits are made here
> > - This is where topic-branches are merged into.
> >
> > Cutting a release:
> > 1. git checkout next && git merge --ff-only master
> > 2. Test test test!
> > 3. Fix bugs by committing them directly to "next" and then doing a non-ff
> > merge of next into master
> > 4. Tag release candidate
> > 5. Repeat steps 2-4 as necessary
> > 6. Tag the release (both by version and by updating the "latest" tag)
> > 7. Create distribution .zip file
> > 8. Test one last time using the dist files
> >
> >
> >
> >
> >
> >
> >
> > >
> > > Thanks,
> > > Michael
> > >
> > > On Wed, Jan 23, 2013 at 11:25 AM, Brian LeRoux <b...@brian.io> wrote:
> > >
> > >> I'm liking it. Start in 2.5?
> > >>
> > >> On Wed, Jan 23, 2013 at 1:19 PM, Filip Maj <fi...@adobe.com> wrote:
> > >>> Looks great Andrew!
> > >>>
> > >>> If everyone's on board, how are we going to test run this? Flip a
> > > switch
> > >>> at a certain point, give it a shot with one repo for one RC?
> > >>>
> > >>> On 1/22/13 12:29 PM, "Andrew Grieve" <ag...@chromium.org> wrote:
> > >>>
> > >>>> Braden, you're right. I've now done some local playing around in
> git,
> > > and
> > >>>> have an updated proposal that uses merges instead of deleting
> > branches.
> > >>>> PTAL:
> > >>>>
> > >>>> Cordova repositories have three main branches:
> > >>>> 1. stable
> > >>>> 2. next
> > >>>> 3. dev
> > >>>>
> > >>>> Topic branches also exist for collaborating on features, or for
> > >>>> code-review
> > >>>> purposes.
> > >>>>
> > >>>> There is *no* master branch, so that community-driven pull requests
> > > will
> > >>>> be
> > >>>> forced to think about which branch to request against.
> > >>>>
> > >>>> 1. The "stable" branch.
> > >>>> - Sits at the latest stable release of cordova
> > >>>> - This changes only when doing fast-forward merges from "next"
> > >>>>
> > >>>> 2. The "next" branch.
> > >>>> - This branch is used only when in the process of doing a release.
> > >>>> - All tags (both stable and RC) are done on this branch.
> > >>>> - All release-candidate bug-fixes are done on this branch.
> > >>>>
> > >>>> 3. The "dev" branch.
> > >>>> - This is where non-release-candidate commits are done
> > >>>> - This is where topic-branches are merged into.
> > >>>>
> > >>>> Cutting a release:
> > >>>> 1. git checkout next && git merge --ff-only dev
> > >>>> 2. Test test test!
> > >>>> 3. Fix bugs by committing them directly to "next" and then doing a
> > > non-ff
> > >>>> merge of next into dev
> > >>>> 4. Tag release candidate
> > >>>> 5. Repeat steps 2-4 as necessary
> > >>>> 6. Tag the release
> > >>>> 7. Create distribution .zip file
> > >>>> 8. Test one last time using the dist files
> > >>>> 9. git checkout stable && git merge --ff-only next
> > >>>>
> > >>>>
> > >>>>
> > >>>> On Tue, Jan 22, 2013 at 1:59 PM, Braden Shepherdson
> > >>>> <br...@chromium.org>wrote:
> > >>>>
> > >>>>> I think deleting and recreating branches with the same name can
> cause
> > >>>>> badness in git[1] because of remotes. It's not really the same
> branch
> > >> in
> > >>>>> terms of commits, and git thinks that your old stable and the new
> > >> stable
> > >>>>> differ by all of each of their commits. Tags can be moved
> > > arbitrarily,
> > >>>>> so I
> > >>>>> think stable makes sense as a tag. I'm not sure about how best to
> > >> handle
> > >>>>> next.
> > >>>>>
> > >>>>> [1]
> > >
> >
> http://stackoverflow.com/questions/11844581/git-delete-and-recreate-branc
> > >>>>> h
> > >>>>>
> > >>>>>
> > >>>>> On Tue, Jan 22, 2013 at 11:31 AM, Andrew Grieve <
> > > agrieve@chromium.org
> > >>>>>> wrote:
> > >>>>>
> > >>>>>> Michal's attending hackathons for the week, and I'm not sure we
> > > need
> > >>>>> to
> > >>>>> do
> > >>>>>> a hang-out for this, as I think we really are quite close to
> > >> resolving
> > >>>>>> this. I'd really like to resolve this ASAP so that we don't need
> to
> > >>>>> have
> > >>>>> a
> > >>>>>> code-freeze for this release.
> > >>>>>>
> > >>>>>> Here's a proposal:
> > >>>>>>
> > >>>>>> Cordova repositories have three main branches:
> > >>>>>> 1. stable
> > >>>>>> 2. next
> > >>>>>> 3. dev
> > >>>>>>
> > >>>>>> Topic branches also exist for collaborating on features, or for
> > >>>>> code-review
> > >>>>>> purposes.
> > >>>>>>
> > >>>>>> There is *no* master branch, so that community-driven pull
> requests
> > >>>>> will
> > >>>>> be
> > >>>>>> forced to think about which branch to request against.
> > >>>>>>
> > >>>>>> 1. The "stable" branch.
> > >>>>>> - Sits at the latest stable release of cordova
> > >>>>>> - No one ever commits to the "stable" branch. It exists only as a
> > >>>>>> short-cut for checking out the latest stable tag.
> > >>>>>>
> > >>>>>> 2. The "next" branch.
> > >>>>>> - This branch exists only when in the process of doing a release.
> > >>>>>> - All tags (both stable and RC) are done on this branch.
> > >>>>>> - When a stable tag is done:
> > >>>>>> - The existing "stable" branch is deleted
> > >>>>>> - A new "stable" branch is created from "next".
> > >>>>>> - The "next" branch is deleted.
> > >>>>>>
> > >>>>>> 3. The "dev" branch.
> > >>>>>> - This is where all commits are done
> > >>>>>> - This is where topic-branches are merged into.
> > >>>>>>
> > >>>>>> Cutting a release:
> > >>>>>> 1. Create "next" from the HEAD of "dev"
> > >>>>>> 2. Test test test!
> > >>>>>> 3. Fix bugs by committing them to "dev" and then cherry-picking
> > > them
> > >>>>> into
> > >>>>>> "next"
> > >>>>>> 4. Tag release candidate
> > >>>>>> 5. Repeat steps 2-4 as necessary
> > >>>>>> 6. Tag the release
> > >>>>>> 7. Create distribution .zip file
> > >>>>>> 8. Test one last time using the dist files
> > >>>>>> 9. Delete "stable"
> > >>>>>> 10. Create a new "stable" by branching from the HEAD of "next"
> > >>>>>> 11. Delete the "next" branch
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> On Wed, Jan 16, 2013 at 10:34 AM, Michal Mocny <
> > > mmocny@chromium.org>
> > >>>>>> wrote:
> > >>>>>>
> > >>>>>>> Just going to throw out one of my personal requirements for
> > >> whatever
> > >>>>>>> proposal we come up with, so it doesn't get lost:
> > >>>>>>>
> > >>>>>>> * Feature branches are great for feature work and/or large
> > > sweeping
> > >>>>>>> changes, as are JIRA bugs for tracking them, but cordova has many
> > >>>>> many
> > >>>>>>> trivial issues that could be fixed with "drive-by" patches that
> > >>>>> require
> > >>>>>> as
> > >>>>>>> little friction to commit as possible.
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> On Tue, Jan 15, 2013 at 3:05 PM, Marcel Kinard <
> > > cmarcelk@gmail.com
> > >>>
> > >>>>>> wrote:
> > >>>>>>>
> > >>>>>>>> How about if there is a specific straw man proposal at the
> > >>>>> beginning
> > >>>>> of
> > >>>>>>>> the face-time? Then the folks that are in agreement won't need
> > > to
> > >>>>> say
> > >>>>>>>> anything ;-)
> > >>>>>>>>
> > >>>>>>>> Seriously, making adjustments to something tangible is easier
> > >> than
> > >>>>>>>> instantiating it from scratch. A volunteer for a very simple
> > >>>>> writeup
> > >>>>> on
> > >>>>>>> the
> > >>>>>>>> wiki?
> > >>>>>>>>
> > >>>>>>>> -- Marcel Kinard
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> On 1/14/2013 10:06 PM, Michal Mocny wrote:
> > >>>>>>>>
> > >>>>>>>>> Okay gentlemen, I think there have been countless good points
> > >>>>> made
> > >>>>>> from
> > >>>>>>>>> all
> > >>>>>>>>> parties, but also some bike-shedding.
> > >>>>>>>>>
> > >>>>>>>>> Perhaps it is time to schedule some face-time to better
> > >>>>> articulate
> > >>>>>> some
> > >>>>>>> of
> > >>>>>>>>> the finer points, and to help come to some consensus?
> > >>>>>>>>>
> > >>>>>>>>> -Michal
> > >
> >
>
--
@purplecabbage
risingj.com
Re: too long to package a release?
Posted by Braden Shepherdson <br...@chromium.org>.
The founding goal we're trying to accomplish here is that we don't want
everyone sitting on changes to be in the next version while we use master
to prep a release.
I don't think having one branch for prepping the release and another for
main development is a lot of bureaucracy.
On Thu, Jan 24, 2013 at 1:57 PM, Jesse MacFadyen <pu...@gmail.com>wrote:
> I have been quietly listening on this thread, but thought I should at
> least share my opinion.
>
> I don't think adding contribution rules helps anyone. Git is
> complicated enough as it is, and this just all seems like bureaucracy.
>
> I think master should always contain the latest stable code, and be
> periodically tagged with rc's and versions.
> All work should be done in personal forks and feature branches.
> If the latest tag of master is an rc, then we should only be merging
> bugfixes, until the release.
> Immediately after tagging a version we decide which feature branches
> and pull requests to pull in, and go for it.
>
> I don't think this is much different from what we have, but I think
> that is good.
> The suggestions thus far, while interesting, don't increase our
> velocity in my opinion. Also, I can also pretty much guaranty I'll
> screw it up for the next 3-4 versions. ( because I'm dumb )
>
> Cheers,
> Jesse
>
>
>
> On 2013-01-24, at 5:53 AM, Andrew Grieve <ag...@chromium.org> wrote:
>
> On Wed, Jan 23, 2013 at 4:58 PM, Michael Brooks <michael@michaelbrooks.ca
> >wrote:
>
> > Before we move forward, I have a few questions about the "no master"
> > approach.
> >
> > There is *no* master branch, so that community-driven pull requests will
> be
> >> forced to think about which branch to request against.
> >
> >
> > - Andrew, can you cite other projects that do not use a master branch?
> This project is my first time using git / github, so I don't have much to
> draw from. I was going off of others' suggestions on this thread when I
> proposed the names.
>
>
> > - On Github, you must have a default branch. If not master, it must be
> > something else. So, users are not forced to think about the branch to
> send
> > a pull request again... they will likely just use the default.
>
> Hmm, good point. The goal is to get people downloading Cordova for use to
> end up with Stable, and for developers to send pull requests against dev.
> With a forced default branch, I don't think we can accomplish this.
>
>
> >
> > - Why is the "stable" branch not just "master"?
>
> My thinking was that it's not obvious whether Master == bleeding edge, or
> Master == Stable version. Using the names "dev" and "stable" makes it a bit
> clear.
>
>
>
> So... If github forces us to have a default branch, I'm thinking that
> having users send pull requests against "dev" is more valuable than having
> people download the latest "stable" by default. If people are pulling code
> from github rather than from our release .zip files, then it's likely they
> want to hack on it anyways, or that they want the dev version to see if
> bugs are fixed.
>
> Soo.... Here's version #3! If anyone can think of how to keep the three
> branches while addressing being forced to have a default branch, feel free
> to speak up! :)
>
>
> Cordova repositories have two main branches:
> 1. master
> 2. next
>
> Topic branches exist for collaborating on features, or for code-review
> purposes.
>
> Cordova uses tags to label releases.
> - Each release candidate has a tag. e.g. "2.2.0rc1"
> - Each release has a tag. e.g. "2.2.0"
> - The "latest" tag points to the last stable release (this follows npm
> conventions)
>
>
> 1. The "next" branch.
> - This branch is used only when in the process of doing a release.
> - All tags are created from this branch.
> - All release-candidate bug-fixes are done on this branch.
>
> 2. The "master" branch.
> - When not in the release-process, all commits are made here
> - When in the release-process, all non-bugfix commits are made here
> - This is where topic-branches are merged into.
>
> Cutting a release:
> 1. git checkout next && git merge --ff-only master
> 2. Test test test!
> 3. Fix bugs by committing them directly to "next" and then doing a non-ff
> merge of next into master
> 4. Tag release candidate
> 5. Repeat steps 2-4 as necessary
> 6. Tag the release (both by version and by updating the "latest" tag)
> 7. Create distribution .zip file
> 8. Test one last time using the dist files
>
>
>
>
>
>
>
> >
> > Thanks,
> > Michael
> >
> > On Wed, Jan 23, 2013 at 11:25 AM, Brian LeRoux <b...@brian.io> wrote:
> >
> >> I'm liking it. Start in 2.5?
> >>
> >> On Wed, Jan 23, 2013 at 1:19 PM, Filip Maj <fi...@adobe.com> wrote:
> >>> Looks great Andrew!
> >>>
> >>> If everyone's on board, how are we going to test run this? Flip a
> > switch
> >>> at a certain point, give it a shot with one repo for one RC?
> >>>
> >>> On 1/22/13 12:29 PM, "Andrew Grieve" <ag...@chromium.org> wrote:
> >>>
> >>>> Braden, you're right. I've now done some local playing around in git,
> > and
> >>>> have an updated proposal that uses merges instead of deleting
> branches.
> >>>> PTAL:
> >>>>
> >>>> Cordova repositories have three main branches:
> >>>> 1. stable
> >>>> 2. next
> >>>> 3. dev
> >>>>
> >>>> Topic branches also exist for collaborating on features, or for
> >>>> code-review
> >>>> purposes.
> >>>>
> >>>> There is *no* master branch, so that community-driven pull requests
> > will
> >>>> be
> >>>> forced to think about which branch to request against.
> >>>>
> >>>> 1. The "stable" branch.
> >>>> - Sits at the latest stable release of cordova
> >>>> - This changes only when doing fast-forward merges from "next"
> >>>>
> >>>> 2. The "next" branch.
> >>>> - This branch is used only when in the process of doing a release.
> >>>> - All tags (both stable and RC) are done on this branch.
> >>>> - All release-candidate bug-fixes are done on this branch.
> >>>>
> >>>> 3. The "dev" branch.
> >>>> - This is where non-release-candidate commits are done
> >>>> - This is where topic-branches are merged into.
> >>>>
> >>>> Cutting a release:
> >>>> 1. git checkout next && git merge --ff-only dev
> >>>> 2. Test test test!
> >>>> 3. Fix bugs by committing them directly to "next" and then doing a
> > non-ff
> >>>> merge of next into dev
> >>>> 4. Tag release candidate
> >>>> 5. Repeat steps 2-4 as necessary
> >>>> 6. Tag the release
> >>>> 7. Create distribution .zip file
> >>>> 8. Test one last time using the dist files
> >>>> 9. git checkout stable && git merge --ff-only next
> >>>>
> >>>>
> >>>>
> >>>> On Tue, Jan 22, 2013 at 1:59 PM, Braden Shepherdson
> >>>> <br...@chromium.org>wrote:
> >>>>
> >>>>> I think deleting and recreating branches with the same name can cause
> >>>>> badness in git[1] because of remotes. It's not really the same branch
> >> in
> >>>>> terms of commits, and git thinks that your old stable and the new
> >> stable
> >>>>> differ by all of each of their commits. Tags can be moved
> > arbitrarily,
> >>>>> so I
> >>>>> think stable makes sense as a tag. I'm not sure about how best to
> >> handle
> >>>>> next.
> >>>>>
> >>>>> [1]
> >
> http://stackoverflow.com/questions/11844581/git-delete-and-recreate-branc
> >>>>> h
> >>>>>
> >>>>>
> >>>>> On Tue, Jan 22, 2013 at 11:31 AM, Andrew Grieve <
> > agrieve@chromium.org
> >>>>>> wrote:
> >>>>>
> >>>>>> Michal's attending hackathons for the week, and I'm not sure we
> > need
> >>>>> to
> >>>>> do
> >>>>>> a hang-out for this, as I think we really are quite close to
> >> resolving
> >>>>>> this. I'd really like to resolve this ASAP so that we don't need to
> >>>>> have
> >>>>> a
> >>>>>> code-freeze for this release.
> >>>>>>
> >>>>>> Here's a proposal:
> >>>>>>
> >>>>>> Cordova repositories have three main branches:
> >>>>>> 1. stable
> >>>>>> 2. next
> >>>>>> 3. dev
> >>>>>>
> >>>>>> Topic branches also exist for collaborating on features, or for
> >>>>> code-review
> >>>>>> purposes.
> >>>>>>
> >>>>>> There is *no* master branch, so that community-driven pull requests
> >>>>> will
> >>>>> be
> >>>>>> forced to think about which branch to request against.
> >>>>>>
> >>>>>> 1. The "stable" branch.
> >>>>>> - Sits at the latest stable release of cordova
> >>>>>> - No one ever commits to the "stable" branch. It exists only as a
> >>>>>> short-cut for checking out the latest stable tag.
> >>>>>>
> >>>>>> 2. The "next" branch.
> >>>>>> - This branch exists only when in the process of doing a release.
> >>>>>> - All tags (both stable and RC) are done on this branch.
> >>>>>> - When a stable tag is done:
> >>>>>> - The existing "stable" branch is deleted
> >>>>>> - A new "stable" branch is created from "next".
> >>>>>> - The "next" branch is deleted.
> >>>>>>
> >>>>>> 3. The "dev" branch.
> >>>>>> - This is where all commits are done
> >>>>>> - This is where topic-branches are merged into.
> >>>>>>
> >>>>>> Cutting a release:
> >>>>>> 1. Create "next" from the HEAD of "dev"
> >>>>>> 2. Test test test!
> >>>>>> 3. Fix bugs by committing them to "dev" and then cherry-picking
> > them
> >>>>> into
> >>>>>> "next"
> >>>>>> 4. Tag release candidate
> >>>>>> 5. Repeat steps 2-4 as necessary
> >>>>>> 6. Tag the release
> >>>>>> 7. Create distribution .zip file
> >>>>>> 8. Test one last time using the dist files
> >>>>>> 9. Delete "stable"
> >>>>>> 10. Create a new "stable" by branching from the HEAD of "next"
> >>>>>> 11. Delete the "next" branch
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Wed, Jan 16, 2013 at 10:34 AM, Michal Mocny <
> > mmocny@chromium.org>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> Just going to throw out one of my personal requirements for
> >> whatever
> >>>>>>> proposal we come up with, so it doesn't get lost:
> >>>>>>>
> >>>>>>> * Feature branches are great for feature work and/or large
> > sweeping
> >>>>>>> changes, as are JIRA bugs for tracking them, but cordova has many
> >>>>> many
> >>>>>>> trivial issues that could be fixed with "drive-by" patches that
> >>>>> require
> >>>>>> as
> >>>>>>> little friction to commit as possible.
> >>>>>>>
> >>>>>>>
> >>>>>>> On Tue, Jan 15, 2013 at 3:05 PM, Marcel Kinard <
> > cmarcelk@gmail.com
> >>>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>>> How about if there is a specific straw man proposal at the
> >>>>> beginning
> >>>>> of
> >>>>>>>> the face-time? Then the folks that are in agreement won't need
> > to
> >>>>> say
> >>>>>>>> anything ;-)
> >>>>>>>>
> >>>>>>>> Seriously, making adjustments to something tangible is easier
> >> than
> >>>>>>>> instantiating it from scratch. A volunteer for a very simple
> >>>>> writeup
> >>>>> on
> >>>>>>> the
> >>>>>>>> wiki?
> >>>>>>>>
> >>>>>>>> -- Marcel Kinard
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 1/14/2013 10:06 PM, Michal Mocny wrote:
> >>>>>>>>
> >>>>>>>>> Okay gentlemen, I think there have been countless good points
> >>>>> made
> >>>>>> from
> >>>>>>>>> all
> >>>>>>>>> parties, but also some bike-shedding.
> >>>>>>>>>
> >>>>>>>>> Perhaps it is time to schedule some face-time to better
> >>>>> articulate
> >>>>>> some
> >>>>>>> of
> >>>>>>>>> the finer points, and to help come to some consensus?
> >>>>>>>>>
> >>>>>>>>> -Michal
> >
>
Re: too long to package a release?
Posted by Jesse MacFadyen <pu...@gmail.com>.
I have been quietly listening on this thread, but thought I should at
least share my opinion.
I don't think adding contribution rules helps anyone. Git is
complicated enough as it is, and this just all seems like bureaucracy.
I think master should always contain the latest stable code, and be
periodically tagged with rc's and versions.
All work should be done in personal forks and feature branches.
If the latest tag of master is an rc, then we should only be merging
bugfixes, until the release.
Immediately after tagging a version we decide which feature branches
and pull requests to pull in, and go for it.
I don't think this is much different from what we have, but I think
that is good.
The suggestions thus far, while interesting, don't increase our
velocity in my opinion. Also, I can also pretty much guaranty I'll
screw it up for the next 3-4 versions. ( because I'm dumb )
Cheers,
Jesse
On 2013-01-24, at 5:53 AM, Andrew Grieve <ag...@chromium.org> wrote:
On Wed, Jan 23, 2013 at 4:58 PM, Michael Brooks <mi...@michaelbrooks.ca>wrote:
> Before we move forward, I have a few questions about the "no master"
> approach.
>
> There is *no* master branch, so that community-driven pull requests will be
>> forced to think about which branch to request against.
>
>
> - Andrew, can you cite other projects that do not use a master branch?
This project is my first time using git / github, so I don't have much to
draw from. I was going off of others' suggestions on this thread when I
proposed the names.
> - On Github, you must have a default branch. If not master, it must be
> something else. So, users are not forced to think about the branch to send
> a pull request again... they will likely just use the default.
Hmm, good point. The goal is to get people downloading Cordova for use to
end up with Stable, and for developers to send pull requests against dev.
With a forced default branch, I don't think we can accomplish this.
>
> - Why is the "stable" branch not just "master"?
My thinking was that it's not obvious whether Master == bleeding edge, or
Master == Stable version. Using the names "dev" and "stable" makes it a bit
clear.
So... If github forces us to have a default branch, I'm thinking that
having users send pull requests against "dev" is more valuable than having
people download the latest "stable" by default. If people are pulling code
from github rather than from our release .zip files, then it's likely they
want to hack on it anyways, or that they want the dev version to see if
bugs are fixed.
Soo.... Here's version #3! If anyone can think of how to keep the three
branches while addressing being forced to have a default branch, feel free
to speak up! :)
Cordova repositories have two main branches:
1. master
2. next
Topic branches exist for collaborating on features, or for code-review
purposes.
Cordova uses tags to label releases.
- Each release candidate has a tag. e.g. "2.2.0rc1"
- Each release has a tag. e.g. "2.2.0"
- The "latest" tag points to the last stable release (this follows npm
conventions)
1. The "next" branch.
- This branch is used only when in the process of doing a release.
- All tags are created from this branch.
- All release-candidate bug-fixes are done on this branch.
2. The "master" branch.
- When not in the release-process, all commits are made here
- When in the release-process, all non-bugfix commits are made here
- This is where topic-branches are merged into.
Cutting a release:
1. git checkout next && git merge --ff-only master
2. Test test test!
3. Fix bugs by committing them directly to "next" and then doing a non-ff
merge of next into master
4. Tag release candidate
5. Repeat steps 2-4 as necessary
6. Tag the release (both by version and by updating the "latest" tag)
7. Create distribution .zip file
8. Test one last time using the dist files
>
> Thanks,
> Michael
>
> On Wed, Jan 23, 2013 at 11:25 AM, Brian LeRoux <b...@brian.io> wrote:
>
>> I'm liking it. Start in 2.5?
>>
>> On Wed, Jan 23, 2013 at 1:19 PM, Filip Maj <fi...@adobe.com> wrote:
>>> Looks great Andrew!
>>>
>>> If everyone's on board, how are we going to test run this? Flip a
> switch
>>> at a certain point, give it a shot with one repo for one RC?
>>>
>>> On 1/22/13 12:29 PM, "Andrew Grieve" <ag...@chromium.org> wrote:
>>>
>>>> Braden, you're right. I've now done some local playing around in git,
> and
>>>> have an updated proposal that uses merges instead of deleting branches.
>>>> PTAL:
>>>>
>>>> Cordova repositories have three main branches:
>>>> 1. stable
>>>> 2. next
>>>> 3. dev
>>>>
>>>> Topic branches also exist for collaborating on features, or for
>>>> code-review
>>>> purposes.
>>>>
>>>> There is *no* master branch, so that community-driven pull requests
> will
>>>> be
>>>> forced to think about which branch to request against.
>>>>
>>>> 1. The "stable" branch.
>>>> - Sits at the latest stable release of cordova
>>>> - This changes only when doing fast-forward merges from "next"
>>>>
>>>> 2. The "next" branch.
>>>> - This branch is used only when in the process of doing a release.
>>>> - All tags (both stable and RC) are done on this branch.
>>>> - All release-candidate bug-fixes are done on this branch.
>>>>
>>>> 3. The "dev" branch.
>>>> - This is where non-release-candidate commits are done
>>>> - This is where topic-branches are merged into.
>>>>
>>>> Cutting a release:
>>>> 1. git checkout next && git merge --ff-only dev
>>>> 2. Test test test!
>>>> 3. Fix bugs by committing them directly to "next" and then doing a
> non-ff
>>>> merge of next into dev
>>>> 4. Tag release candidate
>>>> 5. Repeat steps 2-4 as necessary
>>>> 6. Tag the release
>>>> 7. Create distribution .zip file
>>>> 8. Test one last time using the dist files
>>>> 9. git checkout stable && git merge --ff-only next
>>>>
>>>>
>>>>
>>>> On Tue, Jan 22, 2013 at 1:59 PM, Braden Shepherdson
>>>> <br...@chromium.org>wrote:
>>>>
>>>>> I think deleting and recreating branches with the same name can cause
>>>>> badness in git[1] because of remotes. It's not really the same branch
>> in
>>>>> terms of commits, and git thinks that your old stable and the new
>> stable
>>>>> differ by all of each of their commits. Tags can be moved
> arbitrarily,
>>>>> so I
>>>>> think stable makes sense as a tag. I'm not sure about how best to
>> handle
>>>>> next.
>>>>>
>>>>> [1]
> http://stackoverflow.com/questions/11844581/git-delete-and-recreate-branc
>>>>> h
>>>>>
>>>>>
>>>>> On Tue, Jan 22, 2013 at 11:31 AM, Andrew Grieve <
> agrieve@chromium.org
>>>>>> wrote:
>>>>>
>>>>>> Michal's attending hackathons for the week, and I'm not sure we
> need
>>>>> to
>>>>> do
>>>>>> a hang-out for this, as I think we really are quite close to
>> resolving
>>>>>> this. I'd really like to resolve this ASAP so that we don't need to
>>>>> have
>>>>> a
>>>>>> code-freeze for this release.
>>>>>>
>>>>>> Here's a proposal:
>>>>>>
>>>>>> Cordova repositories have three main branches:
>>>>>> 1. stable
>>>>>> 2. next
>>>>>> 3. dev
>>>>>>
>>>>>> Topic branches also exist for collaborating on features, or for
>>>>> code-review
>>>>>> purposes.
>>>>>>
>>>>>> There is *no* master branch, so that community-driven pull requests
>>>>> will
>>>>> be
>>>>>> forced to think about which branch to request against.
>>>>>>
>>>>>> 1. The "stable" branch.
>>>>>> - Sits at the latest stable release of cordova
>>>>>> - No one ever commits to the "stable" branch. It exists only as a
>>>>>> short-cut for checking out the latest stable tag.
>>>>>>
>>>>>> 2. The "next" branch.
>>>>>> - This branch exists only when in the process of doing a release.
>>>>>> - All tags (both stable and RC) are done on this branch.
>>>>>> - When a stable tag is done:
>>>>>> - The existing "stable" branch is deleted
>>>>>> - A new "stable" branch is created from "next".
>>>>>> - The "next" branch is deleted.
>>>>>>
>>>>>> 3. The "dev" branch.
>>>>>> - This is where all commits are done
>>>>>> - This is where topic-branches are merged into.
>>>>>>
>>>>>> Cutting a release:
>>>>>> 1. Create "next" from the HEAD of "dev"
>>>>>> 2. Test test test!
>>>>>> 3. Fix bugs by committing them to "dev" and then cherry-picking
> them
>>>>> into
>>>>>> "next"
>>>>>> 4. Tag release candidate
>>>>>> 5. Repeat steps 2-4 as necessary
>>>>>> 6. Tag the release
>>>>>> 7. Create distribution .zip file
>>>>>> 8. Test one last time using the dist files
>>>>>> 9. Delete "stable"
>>>>>> 10. Create a new "stable" by branching from the HEAD of "next"
>>>>>> 11. Delete the "next" branch
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Jan 16, 2013 at 10:34 AM, Michal Mocny <
> mmocny@chromium.org>
>>>>>> wrote:
>>>>>>
>>>>>>> Just going to throw out one of my personal requirements for
>> whatever
>>>>>>> proposal we come up with, so it doesn't get lost:
>>>>>>>
>>>>>>> * Feature branches are great for feature work and/or large
> sweeping
>>>>>>> changes, as are JIRA bugs for tracking them, but cordova has many
>>>>> many
>>>>>>> trivial issues that could be fixed with "drive-by" patches that
>>>>> require
>>>>>> as
>>>>>>> little friction to commit as possible.
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Jan 15, 2013 at 3:05 PM, Marcel Kinard <
> cmarcelk@gmail.com
>>>
>>>>>> wrote:
>>>>>>>
>>>>>>>> How about if there is a specific straw man proposal at the
>>>>> beginning
>>>>> of
>>>>>>>> the face-time? Then the folks that are in agreement won't need
> to
>>>>> say
>>>>>>>> anything ;-)
>>>>>>>>
>>>>>>>> Seriously, making adjustments to something tangible is easier
>> than
>>>>>>>> instantiating it from scratch. A volunteer for a very simple
>>>>> writeup
>>>>> on
>>>>>>> the
>>>>>>>> wiki?
>>>>>>>>
>>>>>>>> -- Marcel Kinard
>>>>>>>>
>>>>>>>>
>>>>>>>> On 1/14/2013 10:06 PM, Michal Mocny wrote:
>>>>>>>>
>>>>>>>>> Okay gentlemen, I think there have been countless good points
>>>>> made
>>>>>> from
>>>>>>>>> all
>>>>>>>>> parties, but also some bike-shedding.
>>>>>>>>>
>>>>>>>>> Perhaps it is time to schedule some face-time to better
>>>>> articulate
>>>>>> some
>>>>>>> of
>>>>>>>>> the finer points, and to help come to some consensus?
>>>>>>>>>
>>>>>>>>> -Michal
>
Re: too long to package a release?
Posted by Andrew Grieve <ag...@chromium.org>.
On Wed, Jan 23, 2013 at 4:58 PM, Michael Brooks <mi...@michaelbrooks.ca>wrote:
> Before we move forward, I have a few questions about the "no master"
> approach.
>
> There is *no* master branch, so that community-driven pull requests will be
> > forced to think about which branch to request against.
>
>
> - Andrew, can you cite other projects that do not use a master branch?
>
This project is my first time using git / github, so I don't have much to
draw from. I was going off of others' suggestions on this thread when I
proposed the names.
> - On Github, you must have a default branch. If not master, it must be
> something else. So, users are not forced to think about the branch to send
> a pull request again... they will likely just use the default.
>
Hmm, good point. The goal is to get people downloading Cordova for use to
end up with Stable, and for developers to send pull requests against dev.
With a forced default branch, I don't think we can accomplish this.
>
> - Why is the "stable" branch not just "master"?
>
My thinking was that it's not obvious whether Master == bleeding edge, or
Master == Stable version. Using the names "dev" and "stable" makes it a bit
clear.
So... If github forces us to have a default branch, I'm thinking that
having users send pull requests against "dev" is more valuable than having
people download the latest "stable" by default. If people are pulling code
from github rather than from our release .zip files, then it's likely they
want to hack on it anyways, or that they want the dev version to see if
bugs are fixed.
Soo.... Here's version #3! If anyone can think of how to keep the three
branches while addressing being forced to have a default branch, feel free
to speak up! :)
Cordova repositories have two main branches:
1. master
2. next
Topic branches exist for collaborating on features, or for code-review
purposes.
Cordova uses tags to label releases.
- Each release candidate has a tag. e.g. "2.2.0rc1"
- Each release has a tag. e.g. "2.2.0"
- The "latest" tag points to the last stable release (this follows npm
conventions)
1. The "next" branch.
- This branch is used only when in the process of doing a release.
- All tags are created from this branch.
- All release-candidate bug-fixes are done on this branch.
2. The "master" branch.
- When not in the release-process, all commits are made here
- When in the release-process, all non-bugfix commits are made here
- This is where topic-branches are merged into.
Cutting a release:
1. git checkout next && git merge --ff-only master
2. Test test test!
3. Fix bugs by committing them directly to "next" and then doing a non-ff
merge of next into master
4. Tag release candidate
5. Repeat steps 2-4 as necessary
6. Tag the release (both by version and by updating the "latest" tag)
7. Create distribution .zip file
8. Test one last time using the dist files
>
> Thanks,
> Michael
>
> On Wed, Jan 23, 2013 at 11:25 AM, Brian LeRoux <b...@brian.io> wrote:
>
> > I'm liking it. Start in 2.5?
> >
> > On Wed, Jan 23, 2013 at 1:19 PM, Filip Maj <fi...@adobe.com> wrote:
> > > Looks great Andrew!
> > >
> > > If everyone's on board, how are we going to test run this? Flip a
> switch
> > > at a certain point, give it a shot with one repo for one RC?
> > >
> > > On 1/22/13 12:29 PM, "Andrew Grieve" <ag...@chromium.org> wrote:
> > >
> > >>Braden, you're right. I've now done some local playing around in git,
> and
> > >>have an updated proposal that uses merges instead of deleting branches.
> > >>PTAL:
> > >>
> > >>Cordova repositories have three main branches:
> > >>1. stable
> > >>2. next
> > >>3. dev
> > >>
> > >>Topic branches also exist for collaborating on features, or for
> > >>code-review
> > >>purposes.
> > >>
> > >>There is *no* master branch, so that community-driven pull requests
> will
> > >>be
> > >>forced to think about which branch to request against.
> > >>
> > >>1. The "stable" branch.
> > >> - Sits at the latest stable release of cordova
> > >> - This changes only when doing fast-forward merges from "next"
> > >>
> > >>2. The "next" branch.
> > >> - This branch is used only when in the process of doing a release.
> > >> - All tags (both stable and RC) are done on this branch.
> > >> - All release-candidate bug-fixes are done on this branch.
> > >>
> > >>3. The "dev" branch.
> > >> - This is where non-release-candidate commits are done
> > >> - This is where topic-branches are merged into.
> > >>
> > >>Cutting a release:
> > >>1. git checkout next && git merge --ff-only dev
> > >>2. Test test test!
> > >>3. Fix bugs by committing them directly to "next" and then doing a
> non-ff
> > >>merge of next into dev
> > >>4. Tag release candidate
> > >>5. Repeat steps 2-4 as necessary
> > >>6. Tag the release
> > >>7. Create distribution .zip file
> > >>8. Test one last time using the dist files
> > >>9. git checkout stable && git merge --ff-only next
> > >>
> > >>
> > >>
> > >>On Tue, Jan 22, 2013 at 1:59 PM, Braden Shepherdson
> > >><br...@chromium.org>wrote:
> > >>
> > >>> I think deleting and recreating branches with the same name can cause
> > >>> badness in git[1] because of remotes. It's not really the same branch
> > in
> > >>> terms of commits, and git thinks that your old stable and the new
> > stable
> > >>> differ by all of each of their commits. Tags can be moved
> arbitrarily,
> > >>>so I
> > >>> think stable makes sense as a tag. I'm not sure about how best to
> > handle
> > >>> next.
> > >>>
> > >>> [1]
> > >>>
> > >>>
> >
> http://stackoverflow.com/questions/11844581/git-delete-and-recreate-branc
> > >>>h
> > >>>
> > >>>
> > >>> On Tue, Jan 22, 2013 at 11:31 AM, Andrew Grieve <
> agrieve@chromium.org
> > >>> >wrote:
> > >>>
> > >>> > Michal's attending hackathons for the week, and I'm not sure we
> need
> > >>>to
> > >>> do
> > >>> > a hang-out for this, as I think we really are quite close to
> > resolving
> > >>> > this. I'd really like to resolve this ASAP so that we don't need to
> > >>>have
> > >>> a
> > >>> > code-freeze for this release.
> > >>> >
> > >>> > Here's a proposal:
> > >>> >
> > >>> > Cordova repositories have three main branches:
> > >>> > 1. stable
> > >>> > 2. next
> > >>> > 3. dev
> > >>> >
> > >>> > Topic branches also exist for collaborating on features, or for
> > >>> code-review
> > >>> > purposes.
> > >>> >
> > >>> > There is *no* master branch, so that community-driven pull requests
> > >>>will
> > >>> be
> > >>> > forced to think about which branch to request against.
> > >>> >
> > >>> > 1. The "stable" branch.
> > >>> > - Sits at the latest stable release of cordova
> > >>> > - No one ever commits to the "stable" branch. It exists only as a
> > >>> > short-cut for checking out the latest stable tag.
> > >>> >
> > >>> > 2. The "next" branch.
> > >>> > - This branch exists only when in the process of doing a release.
> > >>> > - All tags (both stable and RC) are done on this branch.
> > >>> > - When a stable tag is done:
> > >>> > - The existing "stable" branch is deleted
> > >>> > - A new "stable" branch is created from "next".
> > >>> > - The "next" branch is deleted.
> > >>> >
> > >>> > 3. The "dev" branch.
> > >>> > - This is where all commits are done
> > >>> > - This is where topic-branches are merged into.
> > >>> >
> > >>> > Cutting a release:
> > >>> > 1. Create "next" from the HEAD of "dev"
> > >>> > 2. Test test test!
> > >>> > 3. Fix bugs by committing them to "dev" and then cherry-picking
> them
> > >>>into
> > >>> > "next"
> > >>> > 4. Tag release candidate
> > >>> > 5. Repeat steps 2-4 as necessary
> > >>> > 6. Tag the release
> > >>> > 7. Create distribution .zip file
> > >>> > 8. Test one last time using the dist files
> > >>> > 9. Delete "stable"
> > >>> > 10. Create a new "stable" by branching from the HEAD of "next"
> > >>> > 11. Delete the "next" branch
> > >>> >
> > >>> >
> > >>> >
> > >>> > On Wed, Jan 16, 2013 at 10:34 AM, Michal Mocny <
> mmocny@chromium.org>
> > >>> > wrote:
> > >>> >
> > >>> > > Just going to throw out one of my personal requirements for
> > whatever
> > >>> > > proposal we come up with, so it doesn't get lost:
> > >>> > >
> > >>> > > * Feature branches are great for feature work and/or large
> sweeping
> > >>> > > changes, as are JIRA bugs for tracking them, but cordova has many
> > >>>many
> > >>> > > trivial issues that could be fixed with "drive-by" patches that
> > >>>require
> > >>> > as
> > >>> > > little friction to commit as possible.
> > >>> > >
> > >>> > >
> > >>> > > On Tue, Jan 15, 2013 at 3:05 PM, Marcel Kinard <
> cmarcelk@gmail.com
> > >
> > >>> > wrote:
> > >>> > >
> > >>> > > > How about if there is a specific straw man proposal at the
> > >>>beginning
> > >>> of
> > >>> > > > the face-time? Then the folks that are in agreement won't need
> to
> > >>>say
> > >>> > > > anything ;-)
> > >>> > > >
> > >>> > > > Seriously, making adjustments to something tangible is easier
> > than
> > >>> > > > instantiating it from scratch. A volunteer for a very simple
> > >>>writeup
> > >>> on
> > >>> > > the
> > >>> > > > wiki?
> > >>> > > >
> > >>> > > > -- Marcel Kinard
> > >>> > > >
> > >>> > > >
> > >>> > > > On 1/14/2013 10:06 PM, Michal Mocny wrote:
> > >>> > > >
> > >>> > > >> Okay gentlemen, I think there have been countless good points
> > >>>made
> > >>> > from
> > >>> > > >> all
> > >>> > > >> parties, but also some bike-shedding.
> > >>> > > >>
> > >>> > > >> Perhaps it is time to schedule some face-time to better
> > >>>articulate
> > >>> > some
> > >>> > > of
> > >>> > > >> the finer points, and to help come to some consensus?
> > >>> > > >>
> > >>> > > >> -Michal
> > >>> > > >>
> > >>> > > >>
> > >>> > > >
> > >>> > >
> > >>> >
> > >>>
> > >
> >
>
Re: too long to package a release?
Posted by Michael Brooks <mi...@michaelbrooks.ca>.
Before we move forward, I have a few questions about the "no master"
approach.
There is *no* master branch, so that community-driven pull requests will be
> forced to think about which branch to request against.
- Andrew, can you cite other projects that do not use a master branch?
- On Github, you must have a default branch. If not master, it must be
something else. So, users are not forced to think about the branch to send
a pull request again... they will likely just use the default.
- Why is the "stable" branch not just "master"?
Thanks,
Michael
On Wed, Jan 23, 2013 at 11:25 AM, Brian LeRoux <b...@brian.io> wrote:
> I'm liking it. Start in 2.5?
>
> On Wed, Jan 23, 2013 at 1:19 PM, Filip Maj <fi...@adobe.com> wrote:
> > Looks great Andrew!
> >
> > If everyone's on board, how are we going to test run this? Flip a switch
> > at a certain point, give it a shot with one repo for one RC?
> >
> > On 1/22/13 12:29 PM, "Andrew Grieve" <ag...@chromium.org> wrote:
> >
> >>Braden, you're right. I've now done some local playing around in git, and
> >>have an updated proposal that uses merges instead of deleting branches.
> >>PTAL:
> >>
> >>Cordova repositories have three main branches:
> >>1. stable
> >>2. next
> >>3. dev
> >>
> >>Topic branches also exist for collaborating on features, or for
> >>code-review
> >>purposes.
> >>
> >>There is *no* master branch, so that community-driven pull requests will
> >>be
> >>forced to think about which branch to request against.
> >>
> >>1. The "stable" branch.
> >> - Sits at the latest stable release of cordova
> >> - This changes only when doing fast-forward merges from "next"
> >>
> >>2. The "next" branch.
> >> - This branch is used only when in the process of doing a release.
> >> - All tags (both stable and RC) are done on this branch.
> >> - All release-candidate bug-fixes are done on this branch.
> >>
> >>3. The "dev" branch.
> >> - This is where non-release-candidate commits are done
> >> - This is where topic-branches are merged into.
> >>
> >>Cutting a release:
> >>1. git checkout next && git merge --ff-only dev
> >>2. Test test test!
> >>3. Fix bugs by committing them directly to "next" and then doing a non-ff
> >>merge of next into dev
> >>4. Tag release candidate
> >>5. Repeat steps 2-4 as necessary
> >>6. Tag the release
> >>7. Create distribution .zip file
> >>8. Test one last time using the dist files
> >>9. git checkout stable && git merge --ff-only next
> >>
> >>
> >>
> >>On Tue, Jan 22, 2013 at 1:59 PM, Braden Shepherdson
> >><br...@chromium.org>wrote:
> >>
> >>> I think deleting and recreating branches with the same name can cause
> >>> badness in git[1] because of remotes. It's not really the same branch
> in
> >>> terms of commits, and git thinks that your old stable and the new
> stable
> >>> differ by all of each of their commits. Tags can be moved arbitrarily,
> >>>so I
> >>> think stable makes sense as a tag. I'm not sure about how best to
> handle
> >>> next.
> >>>
> >>> [1]
> >>>
> >>>
> http://stackoverflow.com/questions/11844581/git-delete-and-recreate-branc
> >>>h
> >>>
> >>>
> >>> On Tue, Jan 22, 2013 at 11:31 AM, Andrew Grieve <agrieve@chromium.org
> >>> >wrote:
> >>>
> >>> > Michal's attending hackathons for the week, and I'm not sure we need
> >>>to
> >>> do
> >>> > a hang-out for this, as I think we really are quite close to
> resolving
> >>> > this. I'd really like to resolve this ASAP so that we don't need to
> >>>have
> >>> a
> >>> > code-freeze for this release.
> >>> >
> >>> > Here's a proposal:
> >>> >
> >>> > Cordova repositories have three main branches:
> >>> > 1. stable
> >>> > 2. next
> >>> > 3. dev
> >>> >
> >>> > Topic branches also exist for collaborating on features, or for
> >>> code-review
> >>> > purposes.
> >>> >
> >>> > There is *no* master branch, so that community-driven pull requests
> >>>will
> >>> be
> >>> > forced to think about which branch to request against.
> >>> >
> >>> > 1. The "stable" branch.
> >>> > - Sits at the latest stable release of cordova
> >>> > - No one ever commits to the "stable" branch. It exists only as a
> >>> > short-cut for checking out the latest stable tag.
> >>> >
> >>> > 2. The "next" branch.
> >>> > - This branch exists only when in the process of doing a release.
> >>> > - All tags (both stable and RC) are done on this branch.
> >>> > - When a stable tag is done:
> >>> > - The existing "stable" branch is deleted
> >>> > - A new "stable" branch is created from "next".
> >>> > - The "next" branch is deleted.
> >>> >
> >>> > 3. The "dev" branch.
> >>> > - This is where all commits are done
> >>> > - This is where topic-branches are merged into.
> >>> >
> >>> > Cutting a release:
> >>> > 1. Create "next" from the HEAD of "dev"
> >>> > 2. Test test test!
> >>> > 3. Fix bugs by committing them to "dev" and then cherry-picking them
> >>>into
> >>> > "next"
> >>> > 4. Tag release candidate
> >>> > 5. Repeat steps 2-4 as necessary
> >>> > 6. Tag the release
> >>> > 7. Create distribution .zip file
> >>> > 8. Test one last time using the dist files
> >>> > 9. Delete "stable"
> >>> > 10. Create a new "stable" by branching from the HEAD of "next"
> >>> > 11. Delete the "next" branch
> >>> >
> >>> >
> >>> >
> >>> > On Wed, Jan 16, 2013 at 10:34 AM, Michal Mocny <mm...@chromium.org>
> >>> > wrote:
> >>> >
> >>> > > Just going to throw out one of my personal requirements for
> whatever
> >>> > > proposal we come up with, so it doesn't get lost:
> >>> > >
> >>> > > * Feature branches are great for feature work and/or large sweeping
> >>> > > changes, as are JIRA bugs for tracking them, but cordova has many
> >>>many
> >>> > > trivial issues that could be fixed with "drive-by" patches that
> >>>require
> >>> > as
> >>> > > little friction to commit as possible.
> >>> > >
> >>> > >
> >>> > > On Tue, Jan 15, 2013 at 3:05 PM, Marcel Kinard <cmarcelk@gmail.com
> >
> >>> > wrote:
> >>> > >
> >>> > > > How about if there is a specific straw man proposal at the
> >>>beginning
> >>> of
> >>> > > > the face-time? Then the folks that are in agreement won't need to
> >>>say
> >>> > > > anything ;-)
> >>> > > >
> >>> > > > Seriously, making adjustments to something tangible is easier
> than
> >>> > > > instantiating it from scratch. A volunteer for a very simple
> >>>writeup
> >>> on
> >>> > > the
> >>> > > > wiki?
> >>> > > >
> >>> > > > -- Marcel Kinard
> >>> > > >
> >>> > > >
> >>> > > > On 1/14/2013 10:06 PM, Michal Mocny wrote:
> >>> > > >
> >>> > > >> Okay gentlemen, I think there have been countless good points
> >>>made
> >>> > from
> >>> > > >> all
> >>> > > >> parties, but also some bike-shedding.
> >>> > > >>
> >>> > > >> Perhaps it is time to schedule some face-time to better
> >>>articulate
> >>> > some
> >>> > > of
> >>> > > >> the finer points, and to help come to some consensus?
> >>> > > >>
> >>> > > >> -Michal
> >>> > > >>
> >>> > > >>
> >>> > > >
> >>> > >
> >>> >
> >>>
> >
>
Re: too long to package a release?
Posted by Brian LeRoux <b...@brian.io>.
I'm liking it. Start in 2.5?
On Wed, Jan 23, 2013 at 1:19 PM, Filip Maj <fi...@adobe.com> wrote:
> Looks great Andrew!
>
> If everyone's on board, how are we going to test run this? Flip a switch
> at a certain point, give it a shot with one repo for one RC?
>
> On 1/22/13 12:29 PM, "Andrew Grieve" <ag...@chromium.org> wrote:
>
>>Braden, you're right. I've now done some local playing around in git, and
>>have an updated proposal that uses merges instead of deleting branches.
>>PTAL:
>>
>>Cordova repositories have three main branches:
>>1. stable
>>2. next
>>3. dev
>>
>>Topic branches also exist for collaborating on features, or for
>>code-review
>>purposes.
>>
>>There is *no* master branch, so that community-driven pull requests will
>>be
>>forced to think about which branch to request against.
>>
>>1. The "stable" branch.
>> - Sits at the latest stable release of cordova
>> - This changes only when doing fast-forward merges from "next"
>>
>>2. The "next" branch.
>> - This branch is used only when in the process of doing a release.
>> - All tags (both stable and RC) are done on this branch.
>> - All release-candidate bug-fixes are done on this branch.
>>
>>3. The "dev" branch.
>> - This is where non-release-candidate commits are done
>> - This is where topic-branches are merged into.
>>
>>Cutting a release:
>>1. git checkout next && git merge --ff-only dev
>>2. Test test test!
>>3. Fix bugs by committing them directly to "next" and then doing a non-ff
>>merge of next into dev
>>4. Tag release candidate
>>5. Repeat steps 2-4 as necessary
>>6. Tag the release
>>7. Create distribution .zip file
>>8. Test one last time using the dist files
>>9. git checkout stable && git merge --ff-only next
>>
>>
>>
>>On Tue, Jan 22, 2013 at 1:59 PM, Braden Shepherdson
>><br...@chromium.org>wrote:
>>
>>> I think deleting and recreating branches with the same name can cause
>>> badness in git[1] because of remotes. It's not really the same branch in
>>> terms of commits, and git thinks that your old stable and the new stable
>>> differ by all of each of their commits. Tags can be moved arbitrarily,
>>>so I
>>> think stable makes sense as a tag. I'm not sure about how best to handle
>>> next.
>>>
>>> [1]
>>>
>>>http://stackoverflow.com/questions/11844581/git-delete-and-recreate-branc
>>>h
>>>
>>>
>>> On Tue, Jan 22, 2013 at 11:31 AM, Andrew Grieve <agrieve@chromium.org
>>> >wrote:
>>>
>>> > Michal's attending hackathons for the week, and I'm not sure we need
>>>to
>>> do
>>> > a hang-out for this, as I think we really are quite close to resolving
>>> > this. I'd really like to resolve this ASAP so that we don't need to
>>>have
>>> a
>>> > code-freeze for this release.
>>> >
>>> > Here's a proposal:
>>> >
>>> > Cordova repositories have three main branches:
>>> > 1. stable
>>> > 2. next
>>> > 3. dev
>>> >
>>> > Topic branches also exist for collaborating on features, or for
>>> code-review
>>> > purposes.
>>> >
>>> > There is *no* master branch, so that community-driven pull requests
>>>will
>>> be
>>> > forced to think about which branch to request against.
>>> >
>>> > 1. The "stable" branch.
>>> > - Sits at the latest stable release of cordova
>>> > - No one ever commits to the "stable" branch. It exists only as a
>>> > short-cut for checking out the latest stable tag.
>>> >
>>> > 2. The "next" branch.
>>> > - This branch exists only when in the process of doing a release.
>>> > - All tags (both stable and RC) are done on this branch.
>>> > - When a stable tag is done:
>>> > - The existing "stable" branch is deleted
>>> > - A new "stable" branch is created from "next".
>>> > - The "next" branch is deleted.
>>> >
>>> > 3. The "dev" branch.
>>> > - This is where all commits are done
>>> > - This is where topic-branches are merged into.
>>> >
>>> > Cutting a release:
>>> > 1. Create "next" from the HEAD of "dev"
>>> > 2. Test test test!
>>> > 3. Fix bugs by committing them to "dev" and then cherry-picking them
>>>into
>>> > "next"
>>> > 4. Tag release candidate
>>> > 5. Repeat steps 2-4 as necessary
>>> > 6. Tag the release
>>> > 7. Create distribution .zip file
>>> > 8. Test one last time using the dist files
>>> > 9. Delete "stable"
>>> > 10. Create a new "stable" by branching from the HEAD of "next"
>>> > 11. Delete the "next" branch
>>> >
>>> >
>>> >
>>> > On Wed, Jan 16, 2013 at 10:34 AM, Michal Mocny <mm...@chromium.org>
>>> > wrote:
>>> >
>>> > > Just going to throw out one of my personal requirements for whatever
>>> > > proposal we come up with, so it doesn't get lost:
>>> > >
>>> > > * Feature branches are great for feature work and/or large sweeping
>>> > > changes, as are JIRA bugs for tracking them, but cordova has many
>>>many
>>> > > trivial issues that could be fixed with "drive-by" patches that
>>>require
>>> > as
>>> > > little friction to commit as possible.
>>> > >
>>> > >
>>> > > On Tue, Jan 15, 2013 at 3:05 PM, Marcel Kinard <cm...@gmail.com>
>>> > wrote:
>>> > >
>>> > > > How about if there is a specific straw man proposal at the
>>>beginning
>>> of
>>> > > > the face-time? Then the folks that are in agreement won't need to
>>>say
>>> > > > anything ;-)
>>> > > >
>>> > > > Seriously, making adjustments to something tangible is easier than
>>> > > > instantiating it from scratch. A volunteer for a very simple
>>>writeup
>>> on
>>> > > the
>>> > > > wiki?
>>> > > >
>>> > > > -- Marcel Kinard
>>> > > >
>>> > > >
>>> > > > On 1/14/2013 10:06 PM, Michal Mocny wrote:
>>> > > >
>>> > > >> Okay gentlemen, I think there have been countless good points
>>>made
>>> > from
>>> > > >> all
>>> > > >> parties, but also some bike-shedding.
>>> > > >>
>>> > > >> Perhaps it is time to schedule some face-time to better
>>>articulate
>>> > some
>>> > > of
>>> > > >> the finer points, and to help come to some consensus?
>>> > > >>
>>> > > >> -Michal
>>> > > >>
>>> > > >>
>>> > > >
>>> > >
>>> >
>>>
>
Re: too long to package a release?
Posted by Andrew Grieve <ag...@chromium.org>.
I won't be at ApacheCon. Don't think Michal/Max/Braden had plans to go
either...
On Tue, Jan 22, 2013 at 3:32 PM, Andrew Grieve <ag...@chromium.org> wrote:
> In google doc form:
> https://docs.google.com/document/d/1s617PCwJm_lOjybHAnkgm5WdoDdU113fkGBCrlPghxE/edit
>
>
> On Tue, Jan 22, 2013 at 3:29 PM, Andrew Grieve <ag...@chromium.org>wrote:
>
>> Cordova repositories have three main branches:
>> 1. stable
>> 2. next
>> 3. dev
>>
>> Topic branches also exist for collaborating on features, or for
>> code-review purposes.
>>
>> There is *no* master branch, so that community-driven pull requests will
>> be forced to think about which branch to request against.
>>
>> 1. The "stable" branch.
>> - Sits at the latest stable release of cordova
>> - This changes only when doing fast-forward merges from "next"
>>
>> 2. The "next" branch.
>> - This branch is used only when in the process of doing a release.
>> - All tags (both stable and RC) are done on this branch.
>> - All release-candidate bug-fixes are done on this branch.
>>
>> 3. The "dev" branch.
>> - This is where non-release-candidate commits are done
>> - This is where topic-branches are merged into.
>>
>> Cutting a release:
>> 1. git checkout next && git merge --ff-only dev
>> 2. Test test test!
>> 3. Fix bugs by committing them directly to "next" and then doing a non-ff
>> merge of next into dev
>> 4. Tag release candidate
>> 5. Repeat steps 2-4 as necessary
>> 6. Tag the release
>> 7. Create distribution .zip file
>> 8. Test one last time using the dist files
>> 9. git checkout stable && git merge --ff-only next
>>
>
>
>
Re: too long to package a release?
Posted by Andrew Grieve <ag...@chromium.org>.
In google doc form:
https://docs.google.com/document/d/1s617PCwJm_lOjybHAnkgm5WdoDdU113fkGBCrlPghxE/edit
On Tue, Jan 22, 2013 at 3:29 PM, Andrew Grieve <ag...@chromium.org> wrote:
> Cordova repositories have three main branches:
> 1. stable
> 2. next
> 3. dev
>
> Topic branches also exist for collaborating on features, or for
> code-review purposes.
>
> There is *no* master branch, so that community-driven pull requests will
> be forced to think about which branch to request against.
>
> 1. The "stable" branch.
> - Sits at the latest stable release of cordova
> - This changes only when doing fast-forward merges from "next"
>
> 2. The "next" branch.
> - This branch is used only when in the process of doing a release.
> - All tags (both stable and RC) are done on this branch.
> - All release-candidate bug-fixes are done on this branch.
>
> 3. The "dev" branch.
> - This is where non-release-candidate commits are done
> - This is where topic-branches are merged into.
>
> Cutting a release:
> 1. git checkout next && git merge --ff-only dev
> 2. Test test test!
> 3. Fix bugs by committing them directly to "next" and then doing a non-ff
> merge of next into dev
> 4. Tag release candidate
> 5. Repeat steps 2-4 as necessary
> 6. Tag the release
> 7. Create distribution .zip file
> 8. Test one last time using the dist files
> 9. git checkout stable && git merge --ff-only next
>
Re: too long to package a release?
Posted by Filip Maj <fi...@adobe.com>.
Looks great Andrew!
If everyone's on board, how are we going to test run this? Flip a switch
at a certain point, give it a shot with one repo for one RC?
On 1/22/13 12:29 PM, "Andrew Grieve" <ag...@chromium.org> wrote:
>Braden, you're right. I've now done some local playing around in git, and
>have an updated proposal that uses merges instead of deleting branches.
>PTAL:
>
>Cordova repositories have three main branches:
>1. stable
>2. next
>3. dev
>
>Topic branches also exist for collaborating on features, or for
>code-review
>purposes.
>
>There is *no* master branch, so that community-driven pull requests will
>be
>forced to think about which branch to request against.
>
>1. The "stable" branch.
> - Sits at the latest stable release of cordova
> - This changes only when doing fast-forward merges from "next"
>
>2. The "next" branch.
> - This branch is used only when in the process of doing a release.
> - All tags (both stable and RC) are done on this branch.
> - All release-candidate bug-fixes are done on this branch.
>
>3. The "dev" branch.
> - This is where non-release-candidate commits are done
> - This is where topic-branches are merged into.
>
>Cutting a release:
>1. git checkout next && git merge --ff-only dev
>2. Test test test!
>3. Fix bugs by committing them directly to "next" and then doing a non-ff
>merge of next into dev
>4. Tag release candidate
>5. Repeat steps 2-4 as necessary
>6. Tag the release
>7. Create distribution .zip file
>8. Test one last time using the dist files
>9. git checkout stable && git merge --ff-only next
>
>
>
>On Tue, Jan 22, 2013 at 1:59 PM, Braden Shepherdson
><br...@chromium.org>wrote:
>
>> I think deleting and recreating branches with the same name can cause
>> badness in git[1] because of remotes. It's not really the same branch in
>> terms of commits, and git thinks that your old stable and the new stable
>> differ by all of each of their commits. Tags can be moved arbitrarily,
>>so I
>> think stable makes sense as a tag. I'm not sure about how best to handle
>> next.
>>
>> [1]
>>
>>http://stackoverflow.com/questions/11844581/git-delete-and-recreate-branc
>>h
>>
>>
>> On Tue, Jan 22, 2013 at 11:31 AM, Andrew Grieve <agrieve@chromium.org
>> >wrote:
>>
>> > Michal's attending hackathons for the week, and I'm not sure we need
>>to
>> do
>> > a hang-out for this, as I think we really are quite close to resolving
>> > this. I'd really like to resolve this ASAP so that we don't need to
>>have
>> a
>> > code-freeze for this release.
>> >
>> > Here's a proposal:
>> >
>> > Cordova repositories have three main branches:
>> > 1. stable
>> > 2. next
>> > 3. dev
>> >
>> > Topic branches also exist for collaborating on features, or for
>> code-review
>> > purposes.
>> >
>> > There is *no* master branch, so that community-driven pull requests
>>will
>> be
>> > forced to think about which branch to request against.
>> >
>> > 1. The "stable" branch.
>> > - Sits at the latest stable release of cordova
>> > - No one ever commits to the "stable" branch. It exists only as a
>> > short-cut for checking out the latest stable tag.
>> >
>> > 2. The "next" branch.
>> > - This branch exists only when in the process of doing a release.
>> > - All tags (both stable and RC) are done on this branch.
>> > - When a stable tag is done:
>> > - The existing "stable" branch is deleted
>> > - A new "stable" branch is created from "next".
>> > - The "next" branch is deleted.
>> >
>> > 3. The "dev" branch.
>> > - This is where all commits are done
>> > - This is where topic-branches are merged into.
>> >
>> > Cutting a release:
>> > 1. Create "next" from the HEAD of "dev"
>> > 2. Test test test!
>> > 3. Fix bugs by committing them to "dev" and then cherry-picking them
>>into
>> > "next"
>> > 4. Tag release candidate
>> > 5. Repeat steps 2-4 as necessary
>> > 6. Tag the release
>> > 7. Create distribution .zip file
>> > 8. Test one last time using the dist files
>> > 9. Delete "stable"
>> > 10. Create a new "stable" by branching from the HEAD of "next"
>> > 11. Delete the "next" branch
>> >
>> >
>> >
>> > On Wed, Jan 16, 2013 at 10:34 AM, Michal Mocny <mm...@chromium.org>
>> > wrote:
>> >
>> > > Just going to throw out one of my personal requirements for whatever
>> > > proposal we come up with, so it doesn't get lost:
>> > >
>> > > * Feature branches are great for feature work and/or large sweeping
>> > > changes, as are JIRA bugs for tracking them, but cordova has many
>>many
>> > > trivial issues that could be fixed with "drive-by" patches that
>>require
>> > as
>> > > little friction to commit as possible.
>> > >
>> > >
>> > > On Tue, Jan 15, 2013 at 3:05 PM, Marcel Kinard <cm...@gmail.com>
>> > wrote:
>> > >
>> > > > How about if there is a specific straw man proposal at the
>>beginning
>> of
>> > > > the face-time? Then the folks that are in agreement won't need to
>>say
>> > > > anything ;-)
>> > > >
>> > > > Seriously, making adjustments to something tangible is easier than
>> > > > instantiating it from scratch. A volunteer for a very simple
>>writeup
>> on
>> > > the
>> > > > wiki?
>> > > >
>> > > > -- Marcel Kinard
>> > > >
>> > > >
>> > > > On 1/14/2013 10:06 PM, Michal Mocny wrote:
>> > > >
>> > > >> Okay gentlemen, I think there have been countless good points
>>made
>> > from
>> > > >> all
>> > > >> parties, but also some bike-shedding.
>> > > >>
>> > > >> Perhaps it is time to schedule some face-time to better
>>articulate
>> > some
>> > > of
>> > > >> the finer points, and to help come to some consensus?
>> > > >>
>> > > >> -Michal
>> > > >>
>> > > >>
>> > > >
>> > >
>> >
>>
Re: too long to package a release?
Posted by Andrew Grieve <ag...@chromium.org>.
Braden, you're right. I've now done some local playing around in git, and
have an updated proposal that uses merges instead of deleting branches.
PTAL:
Cordova repositories have three main branches:
1. stable
2. next
3. dev
Topic branches also exist for collaborating on features, or for code-review
purposes.
There is *no* master branch, so that community-driven pull requests will be
forced to think about which branch to request against.
1. The "stable" branch.
- Sits at the latest stable release of cordova
- This changes only when doing fast-forward merges from "next"
2. The "next" branch.
- This branch is used only when in the process of doing a release.
- All tags (both stable and RC) are done on this branch.
- All release-candidate bug-fixes are done on this branch.
3. The "dev" branch.
- This is where non-release-candidate commits are done
- This is where topic-branches are merged into.
Cutting a release:
1. git checkout next && git merge --ff-only dev
2. Test test test!
3. Fix bugs by committing them directly to "next" and then doing a non-ff
merge of next into dev
4. Tag release candidate
5. Repeat steps 2-4 as necessary
6. Tag the release
7. Create distribution .zip file
8. Test one last time using the dist files
9. git checkout stable && git merge --ff-only next
On Tue, Jan 22, 2013 at 1:59 PM, Braden Shepherdson <br...@chromium.org>wrote:
> I think deleting and recreating branches with the same name can cause
> badness in git[1] because of remotes. It's not really the same branch in
> terms of commits, and git thinks that your old stable and the new stable
> differ by all of each of their commits. Tags can be moved arbitrarily, so I
> think stable makes sense as a tag. I'm not sure about how best to handle
> next.
>
> [1]
> http://stackoverflow.com/questions/11844581/git-delete-and-recreate-branch
>
>
> On Tue, Jan 22, 2013 at 11:31 AM, Andrew Grieve <agrieve@chromium.org
> >wrote:
>
> > Michal's attending hackathons for the week, and I'm not sure we need to
> do
> > a hang-out for this, as I think we really are quite close to resolving
> > this. I'd really like to resolve this ASAP so that we don't need to have
> a
> > code-freeze for this release.
> >
> > Here's a proposal:
> >
> > Cordova repositories have three main branches:
> > 1. stable
> > 2. next
> > 3. dev
> >
> > Topic branches also exist for collaborating on features, or for
> code-review
> > purposes.
> >
> > There is *no* master branch, so that community-driven pull requests will
> be
> > forced to think about which branch to request against.
> >
> > 1. The "stable" branch.
> > - Sits at the latest stable release of cordova
> > - No one ever commits to the "stable" branch. It exists only as a
> > short-cut for checking out the latest stable tag.
> >
> > 2. The "next" branch.
> > - This branch exists only when in the process of doing a release.
> > - All tags (both stable and RC) are done on this branch.
> > - When a stable tag is done:
> > - The existing "stable" branch is deleted
> > - A new "stable" branch is created from "next".
> > - The "next" branch is deleted.
> >
> > 3. The "dev" branch.
> > - This is where all commits are done
> > - This is where topic-branches are merged into.
> >
> > Cutting a release:
> > 1. Create "next" from the HEAD of "dev"
> > 2. Test test test!
> > 3. Fix bugs by committing them to "dev" and then cherry-picking them into
> > "next"
> > 4. Tag release candidate
> > 5. Repeat steps 2-4 as necessary
> > 6. Tag the release
> > 7. Create distribution .zip file
> > 8. Test one last time using the dist files
> > 9. Delete "stable"
> > 10. Create a new "stable" by branching from the HEAD of "next"
> > 11. Delete the "next" branch
> >
> >
> >
> > On Wed, Jan 16, 2013 at 10:34 AM, Michal Mocny <mm...@chromium.org>
> > wrote:
> >
> > > Just going to throw out one of my personal requirements for whatever
> > > proposal we come up with, so it doesn't get lost:
> > >
> > > * Feature branches are great for feature work and/or large sweeping
> > > changes, as are JIRA bugs for tracking them, but cordova has many many
> > > trivial issues that could be fixed with "drive-by" patches that require
> > as
> > > little friction to commit as possible.
> > >
> > >
> > > On Tue, Jan 15, 2013 at 3:05 PM, Marcel Kinard <cm...@gmail.com>
> > wrote:
> > >
> > > > How about if there is a specific straw man proposal at the beginning
> of
> > > > the face-time? Then the folks that are in agreement won't need to say
> > > > anything ;-)
> > > >
> > > > Seriously, making adjustments to something tangible is easier than
> > > > instantiating it from scratch. A volunteer for a very simple writeup
> on
> > > the
> > > > wiki?
> > > >
> > > > -- Marcel Kinard
> > > >
> > > >
> > > > On 1/14/2013 10:06 PM, Michal Mocny wrote:
> > > >
> > > >> Okay gentlemen, I think there have been countless good points made
> > from
> > > >> all
> > > >> parties, but also some bike-shedding.
> > > >>
> > > >> Perhaps it is time to schedule some face-time to better articulate
> > some
> > > of
> > > >> the finer points, and to help come to some consensus?
> > > >>
> > > >> -Michal
> > > >>
> > > >>
> > > >
> > >
> >
>
Re: too long to package a release?
Posted by Filip Maj <fi...@adobe.com>.
Are other committers not from Adobe attending apache con? If so maybe a
meeting in person to discuss this would help.
On 1/22/13 11:52 AM, "Brian LeRoux" <b...@brian.io> wrote:
>Talking w/ Dr. David Charles Johnson about this. We think a F2F would
>help but before we go that far I think your proposal is close Andrew.
>How about firing it into a Google Doc for commenting/and revisioning?
>
>On Tue, Jan 22, 2013 at 12:59 PM, Braden Shepherdson
><br...@chromium.org> wrote:
>> I think deleting and recreating branches with the same name can cause
>> badness in git[1] because of remotes. It's not really the same branch in
>> terms of commits, and git thinks that your old stable and the new stable
>> differ by all of each of their commits. Tags can be moved arbitrarily,
>>so I
>> think stable makes sense as a tag. I'm not sure about how best to handle
>> next.
>>
>> [1]
>>
>>http://stackoverflow.com/questions/11844581/git-delete-and-recreate-branc
>>h
>>
>>
>> On Tue, Jan 22, 2013 at 11:31 AM, Andrew Grieve
>><ag...@chromium.org>wrote:
>>
>>> Michal's attending hackathons for the week, and I'm not sure we need
>>>to do
>>> a hang-out for this, as I think we really are quite close to resolving
>>> this. I'd really like to resolve this ASAP so that we don't need to
>>>have a
>>> code-freeze for this release.
>>>
>>> Here's a proposal:
>>>
>>> Cordova repositories have three main branches:
>>> 1. stable
>>> 2. next
>>> 3. dev
>>>
>>> Topic branches also exist for collaborating on features, or for
>>>code-review
>>> purposes.
>>>
>>> There is *no* master branch, so that community-driven pull requests
>>>will be
>>> forced to think about which branch to request against.
>>>
>>> 1. The "stable" branch.
>>> - Sits at the latest stable release of cordova
>>> - No one ever commits to the "stable" branch. It exists only as a
>>> short-cut for checking out the latest stable tag.
>>>
>>> 2. The "next" branch.
>>> - This branch exists only when in the process of doing a release.
>>> - All tags (both stable and RC) are done on this branch.
>>> - When a stable tag is done:
>>> - The existing "stable" branch is deleted
>>> - A new "stable" branch is created from "next".
>>> - The "next" branch is deleted.
>>>
>>> 3. The "dev" branch.
>>> - This is where all commits are done
>>> - This is where topic-branches are merged into.
>>>
>>> Cutting a release:
>>> 1. Create "next" from the HEAD of "dev"
>>> 2. Test test test!
>>> 3. Fix bugs by committing them to "dev" and then cherry-picking them
>>>into
>>> "next"
>>> 4. Tag release candidate
>>> 5. Repeat steps 2-4 as necessary
>>> 6. Tag the release
>>> 7. Create distribution .zip file
>>> 8. Test one last time using the dist files
>>> 9. Delete "stable"
>>> 10. Create a new "stable" by branching from the HEAD of "next"
>>> 11. Delete the "next" branch
>>>
>>>
>>>
>>> On Wed, Jan 16, 2013 at 10:34 AM, Michal Mocny <mm...@chromium.org>
>>> wrote:
>>>
>>> > Just going to throw out one of my personal requirements for whatever
>>> > proposal we come up with, so it doesn't get lost:
>>> >
>>> > * Feature branches are great for feature work and/or large sweeping
>>> > changes, as are JIRA bugs for tracking them, but cordova has many
>>>many
>>> > trivial issues that could be fixed with "drive-by" patches that
>>>require
>>> as
>>> > little friction to commit as possible.
>>> >
>>> >
>>> > On Tue, Jan 15, 2013 at 3:05 PM, Marcel Kinard <cm...@gmail.com>
>>> wrote:
>>> >
>>> > > How about if there is a specific straw man proposal at the
>>>beginning of
>>> > > the face-time? Then the folks that are in agreement won't need to
>>>say
>>> > > anything ;-)
>>> > >
>>> > > Seriously, making adjustments to something tangible is easier than
>>> > > instantiating it from scratch. A volunteer for a very simple
>>>writeup on
>>> > the
>>> > > wiki?
>>> > >
>>> > > -- Marcel Kinard
>>> > >
>>> > >
>>> > > On 1/14/2013 10:06 PM, Michal Mocny wrote:
>>> > >
>>> > >> Okay gentlemen, I think there have been countless good points made
>>> from
>>> > >> all
>>> > >> parties, but also some bike-shedding.
>>> > >>
>>> > >> Perhaps it is time to schedule some face-time to better articulate
>>> some
>>> > of
>>> > >> the finer points, and to help come to some consensus?
>>> > >>
>>> > >> -Michal
>>> > >>
>>> > >>
>>> > >
>>> >
>>>
Re: too long to package a release?
Posted by Brian LeRoux <b...@brian.io>.
Talking w/ Dr. David Charles Johnson about this. We think a F2F would
help but before we go that far I think your proposal is close Andrew.
How about firing it into a Google Doc for commenting/and revisioning?
On Tue, Jan 22, 2013 at 12:59 PM, Braden Shepherdson
<br...@chromium.org> wrote:
> I think deleting and recreating branches with the same name can cause
> badness in git[1] because of remotes. It's not really the same branch in
> terms of commits, and git thinks that your old stable and the new stable
> differ by all of each of their commits. Tags can be moved arbitrarily, so I
> think stable makes sense as a tag. I'm not sure about how best to handle
> next.
>
> [1]
> http://stackoverflow.com/questions/11844581/git-delete-and-recreate-branch
>
>
> On Tue, Jan 22, 2013 at 11:31 AM, Andrew Grieve <ag...@chromium.org>wrote:
>
>> Michal's attending hackathons for the week, and I'm not sure we need to do
>> a hang-out for this, as I think we really are quite close to resolving
>> this. I'd really like to resolve this ASAP so that we don't need to have a
>> code-freeze for this release.
>>
>> Here's a proposal:
>>
>> Cordova repositories have three main branches:
>> 1. stable
>> 2. next
>> 3. dev
>>
>> Topic branches also exist for collaborating on features, or for code-review
>> purposes.
>>
>> There is *no* master branch, so that community-driven pull requests will be
>> forced to think about which branch to request against.
>>
>> 1. The "stable" branch.
>> - Sits at the latest stable release of cordova
>> - No one ever commits to the "stable" branch. It exists only as a
>> short-cut for checking out the latest stable tag.
>>
>> 2. The "next" branch.
>> - This branch exists only when in the process of doing a release.
>> - All tags (both stable and RC) are done on this branch.
>> - When a stable tag is done:
>> - The existing "stable" branch is deleted
>> - A new "stable" branch is created from "next".
>> - The "next" branch is deleted.
>>
>> 3. The "dev" branch.
>> - This is where all commits are done
>> - This is where topic-branches are merged into.
>>
>> Cutting a release:
>> 1. Create "next" from the HEAD of "dev"
>> 2. Test test test!
>> 3. Fix bugs by committing them to "dev" and then cherry-picking them into
>> "next"
>> 4. Tag release candidate
>> 5. Repeat steps 2-4 as necessary
>> 6. Tag the release
>> 7. Create distribution .zip file
>> 8. Test one last time using the dist files
>> 9. Delete "stable"
>> 10. Create a new "stable" by branching from the HEAD of "next"
>> 11. Delete the "next" branch
>>
>>
>>
>> On Wed, Jan 16, 2013 at 10:34 AM, Michal Mocny <mm...@chromium.org>
>> wrote:
>>
>> > Just going to throw out one of my personal requirements for whatever
>> > proposal we come up with, so it doesn't get lost:
>> >
>> > * Feature branches are great for feature work and/or large sweeping
>> > changes, as are JIRA bugs for tracking them, but cordova has many many
>> > trivial issues that could be fixed with "drive-by" patches that require
>> as
>> > little friction to commit as possible.
>> >
>> >
>> > On Tue, Jan 15, 2013 at 3:05 PM, Marcel Kinard <cm...@gmail.com>
>> wrote:
>> >
>> > > How about if there is a specific straw man proposal at the beginning of
>> > > the face-time? Then the folks that are in agreement won't need to say
>> > > anything ;-)
>> > >
>> > > Seriously, making adjustments to something tangible is easier than
>> > > instantiating it from scratch. A volunteer for a very simple writeup on
>> > the
>> > > wiki?
>> > >
>> > > -- Marcel Kinard
>> > >
>> > >
>> > > On 1/14/2013 10:06 PM, Michal Mocny wrote:
>> > >
>> > >> Okay gentlemen, I think there have been countless good points made
>> from
>> > >> all
>> > >> parties, but also some bike-shedding.
>> > >>
>> > >> Perhaps it is time to schedule some face-time to better articulate
>> some
>> > of
>> > >> the finer points, and to help come to some consensus?
>> > >>
>> > >> -Michal
>> > >>
>> > >>
>> > >
>> >
>>
Re: too long to package a release?
Posted by Braden Shepherdson <br...@chromium.org>.
I think deleting and recreating branches with the same name can cause
badness in git[1] because of remotes. It's not really the same branch in
terms of commits, and git thinks that your old stable and the new stable
differ by all of each of their commits. Tags can be moved arbitrarily, so I
think stable makes sense as a tag. I'm not sure about how best to handle
next.
[1]
http://stackoverflow.com/questions/11844581/git-delete-and-recreate-branch
On Tue, Jan 22, 2013 at 11:31 AM, Andrew Grieve <ag...@chromium.org>wrote:
> Michal's attending hackathons for the week, and I'm not sure we need to do
> a hang-out for this, as I think we really are quite close to resolving
> this. I'd really like to resolve this ASAP so that we don't need to have a
> code-freeze for this release.
>
> Here's a proposal:
>
> Cordova repositories have three main branches:
> 1. stable
> 2. next
> 3. dev
>
> Topic branches also exist for collaborating on features, or for code-review
> purposes.
>
> There is *no* master branch, so that community-driven pull requests will be
> forced to think about which branch to request against.
>
> 1. The "stable" branch.
> - Sits at the latest stable release of cordova
> - No one ever commits to the "stable" branch. It exists only as a
> short-cut for checking out the latest stable tag.
>
> 2. The "next" branch.
> - This branch exists only when in the process of doing a release.
> - All tags (both stable and RC) are done on this branch.
> - When a stable tag is done:
> - The existing "stable" branch is deleted
> - A new "stable" branch is created from "next".
> - The "next" branch is deleted.
>
> 3. The "dev" branch.
> - This is where all commits are done
> - This is where topic-branches are merged into.
>
> Cutting a release:
> 1. Create "next" from the HEAD of "dev"
> 2. Test test test!
> 3. Fix bugs by committing them to "dev" and then cherry-picking them into
> "next"
> 4. Tag release candidate
> 5. Repeat steps 2-4 as necessary
> 6. Tag the release
> 7. Create distribution .zip file
> 8. Test one last time using the dist files
> 9. Delete "stable"
> 10. Create a new "stable" by branching from the HEAD of "next"
> 11. Delete the "next" branch
>
>
>
> On Wed, Jan 16, 2013 at 10:34 AM, Michal Mocny <mm...@chromium.org>
> wrote:
>
> > Just going to throw out one of my personal requirements for whatever
> > proposal we come up with, so it doesn't get lost:
> >
> > * Feature branches are great for feature work and/or large sweeping
> > changes, as are JIRA bugs for tracking them, but cordova has many many
> > trivial issues that could be fixed with "drive-by" patches that require
> as
> > little friction to commit as possible.
> >
> >
> > On Tue, Jan 15, 2013 at 3:05 PM, Marcel Kinard <cm...@gmail.com>
> wrote:
> >
> > > How about if there is a specific straw man proposal at the beginning of
> > > the face-time? Then the folks that are in agreement won't need to say
> > > anything ;-)
> > >
> > > Seriously, making adjustments to something tangible is easier than
> > > instantiating it from scratch. A volunteer for a very simple writeup on
> > the
> > > wiki?
> > >
> > > -- Marcel Kinard
> > >
> > >
> > > On 1/14/2013 10:06 PM, Michal Mocny wrote:
> > >
> > >> Okay gentlemen, I think there have been countless good points made
> from
> > >> all
> > >> parties, but also some bike-shedding.
> > >>
> > >> Perhaps it is time to schedule some face-time to better articulate
> some
> > of
> > >> the finer points, and to help come to some consensus?
> > >>
> > >> -Michal
> > >>
> > >>
> > >
> >
>
Re: too long to package a release?
Posted by Andrew Grieve <ag...@chromium.org>.
Michal's attending hackathons for the week, and I'm not sure we need to do
a hang-out for this, as I think we really are quite close to resolving
this. I'd really like to resolve this ASAP so that we don't need to have a
code-freeze for this release.
Here's a proposal:
Cordova repositories have three main branches:
1. stable
2. next
3. dev
Topic branches also exist for collaborating on features, or for code-review
purposes.
There is *no* master branch, so that community-driven pull requests will be
forced to think about which branch to request against.
1. The "stable" branch.
- Sits at the latest stable release of cordova
- No one ever commits to the "stable" branch. It exists only as a
short-cut for checking out the latest stable tag.
2. The "next" branch.
- This branch exists only when in the process of doing a release.
- All tags (both stable and RC) are done on this branch.
- When a stable tag is done:
- The existing "stable" branch is deleted
- A new "stable" branch is created from "next".
- The "next" branch is deleted.
3. The "dev" branch.
- This is where all commits are done
- This is where topic-branches are merged into.
Cutting a release:
1. Create "next" from the HEAD of "dev"
2. Test test test!
3. Fix bugs by committing them to "dev" and then cherry-picking them into
"next"
4. Tag release candidate
5. Repeat steps 2-4 as necessary
6. Tag the release
7. Create distribution .zip file
8. Test one last time using the dist files
9. Delete "stable"
10. Create a new "stable" by branching from the HEAD of "next"
11. Delete the "next" branch
On Wed, Jan 16, 2013 at 10:34 AM, Michal Mocny <mm...@chromium.org> wrote:
> Just going to throw out one of my personal requirements for whatever
> proposal we come up with, so it doesn't get lost:
>
> * Feature branches are great for feature work and/or large sweeping
> changes, as are JIRA bugs for tracking them, but cordova has many many
> trivial issues that could be fixed with "drive-by" patches that require as
> little friction to commit as possible.
>
>
> On Tue, Jan 15, 2013 at 3:05 PM, Marcel Kinard <cm...@gmail.com> wrote:
>
> > How about if there is a specific straw man proposal at the beginning of
> > the face-time? Then the folks that are in agreement won't need to say
> > anything ;-)
> >
> > Seriously, making adjustments to something tangible is easier than
> > instantiating it from scratch. A volunteer for a very simple writeup on
> the
> > wiki?
> >
> > -- Marcel Kinard
> >
> >
> > On 1/14/2013 10:06 PM, Michal Mocny wrote:
> >
> >> Okay gentlemen, I think there have been countless good points made from
> >> all
> >> parties, but also some bike-shedding.
> >>
> >> Perhaps it is time to schedule some face-time to better articulate some
> of
> >> the finer points, and to help come to some consensus?
> >>
> >> -Michal
> >>
> >>
> >
>
Re: too long to package a release?
Posted by Michal Mocny <mm...@chromium.org>.
Just going to throw out one of my personal requirements for whatever
proposal we come up with, so it doesn't get lost:
* Feature branches are great for feature work and/or large sweeping
changes, as are JIRA bugs for tracking them, but cordova has many many
trivial issues that could be fixed with "drive-by" patches that require as
little friction to commit as possible.
On Tue, Jan 15, 2013 at 3:05 PM, Marcel Kinard <cm...@gmail.com> wrote:
> How about if there is a specific straw man proposal at the beginning of
> the face-time? Then the folks that are in agreement won't need to say
> anything ;-)
>
> Seriously, making adjustments to something tangible is easier than
> instantiating it from scratch. A volunteer for a very simple writeup on the
> wiki?
>
> -- Marcel Kinard
>
>
> On 1/14/2013 10:06 PM, Michal Mocny wrote:
>
>> Okay gentlemen, I think there have been countless good points made from
>> all
>> parties, but also some bike-shedding.
>>
>> Perhaps it is time to schedule some face-time to better articulate some of
>> the finer points, and to help come to some consensus?
>>
>> -Michal
>>
>>
>
Re: too long to package a release?
Posted by Marcel Kinard <cm...@gmail.com>.
How about if there is a specific straw man proposal at the beginning of
the face-time? Then the folks that are in agreement won't need to say
anything ;-)
Seriously, making adjustments to something tangible is easier than
instantiating it from scratch. A volunteer for a very simple writeup on
the wiki?
-- Marcel Kinard
On 1/14/2013 10:06 PM, Michal Mocny wrote:
> Okay gentlemen, I think there have been countless good points made from all
> parties, but also some bike-shedding.
>
> Perhaps it is time to schedule some face-time to better articulate some of
> the finer points, and to help come to some consensus?
>
> -Michal
>
Re: too long to package a release?
Posted by Michal Mocny <mm...@chromium.org>.
Yay for grannies using G+! (mine does, too, which is great, and far less
annoying than her FB game invites!)
On Tue, Jan 15, 2013 at 1:18 PM, Filip Maj <fi...@adobe.com> wrote:
> I was the one who didn't want to sign up for G+ :)
>
> Now it's a moot point as my gramma uses it and so, by proxy, I am required
> to as well :P
>
> On 1/15/13 6:22 AM, "Michal Mocny" <mm...@chromium.org> wrote:
>
> >Thanks for coordinating schedules Brain. Im quite glad to be on EST :)
> >
> >We should also establish a medium: Google hangouts were not well received
> >by everyone last year, (not everyone had a G+ account), but I cannot think
> >of anything that is nearly as convenient. Suggestions?
> >
> >-Michal
> >
> >
> >On Tue, Jan 15, 2013 at 7:52 AM, Becky Gibson
> ><gi...@gmail.com>wrote:
> >
> >> Am I correct in assuming US pacific time zone?
> >>
> >> Sent from my iPad
> >>
> >> On Jan 15, 2013, at 4:36 AM, Brian LeRoux <b...@brian.io> wrote:
> >>
> >> > Works for me, however, to accommodate EU community we must to consider
> >> > times unholy. This is Apache Way from what I understand.
> >> >
> >> > I created a form to help us pick a time to talk.
> >> >
> >> > http://goo.gl/h9d1a
> >> >
> >> >
> >> >
> >> > On Mon, Jan 14, 2013 at 7:06 PM, Michal Mocny <mm...@chromium.org>
> >> wrote:
> >> >> Okay gentlemen, I think there have been countless good points made
> >>from
> >> all
> >> >> parties, but also some bike-shedding.
> >> >>
> >> >> Perhaps it is time to schedule some face-time to better articulate
> >>some
> >> of
> >> >> the finer points, and to help come to some consensus?
> >> >>
> >> >> -Michal
> >> >>
> >> >>
> >> >> On Mon, Jan 14, 2013 at 9:40 PM, Marcel Kinard <cm...@gmail.com>
> >> wrote:
> >> >>
> >> >>> Sorry if this got asked before, but does a feature branch get
> >>deleted
> >> >>> after it is merged? Just wondering about branch clutter over a long
> >> period,
> >> >>> or if this is just the same as a topic branch using today's
> >>committer
> >> >>> workflow.
> >> >>>
> >> >>>
> >> >>> On 1/14/2013 5:34 PM, Brian LeRoux wrote:
> >> >>>
> >> >>>> You work on a Feature branch. It gets rolled into Dev as needed so
> >> >>>> others can merge / collaborate on said feature. When it feels right
> >> >>>> instead of merging a large set of potentially breaking commits to
> >> >>>> Unstable the dev working on said feature just merges that feature.
> >> >>>> This would require more responsibility for the committer to keep
> >>track
> >> >>>> of their feature branches which I could see as being more overhead.
> >> >>>
> >>
>
>
Re: too long to package a release?
Posted by Brian LeRoux <b...@brian.io>.
Becky: yes PST!
Michal: I can setup a bridge using either Gotomeeting (Citrix, Java)
or Connect (Adobe, Flash). Still a ways out from that WebRTC ideal.
On Tue, Jan 15, 2013 at 6:22 AM, Michal Mocny <mm...@chromium.org> wrote:
> Thanks for coordinating schedules Brain. Im quite glad to be on EST :)
>
> We should also establish a medium: Google hangouts were not well received
> by everyone last year, (not everyone had a G+ account), but I cannot think
> of anything that is nearly as convenient. Suggestions?
>
> -Michal
>
>
> On Tue, Jan 15, 2013 at 7:52 AM, Becky Gibson <gi...@gmail.com>wrote:
>
>> Am I correct in assuming US pacific time zone?
>>
>> Sent from my iPad
>>
>> On Jan 15, 2013, at 4:36 AM, Brian LeRoux <b...@brian.io> wrote:
>>
>> > Works for me, however, to accommodate EU community we must to consider
>> > times unholy. This is Apache Way from what I understand.
>> >
>> > I created a form to help us pick a time to talk.
>> >
>> > http://goo.gl/h9d1a
>> >
>> >
>> >
>> > On Mon, Jan 14, 2013 at 7:06 PM, Michal Mocny <mm...@chromium.org>
>> wrote:
>> >> Okay gentlemen, I think there have been countless good points made from
>> all
>> >> parties, but also some bike-shedding.
>> >>
>> >> Perhaps it is time to schedule some face-time to better articulate some
>> of
>> >> the finer points, and to help come to some consensus?
>> >>
>> >> -Michal
>> >>
>> >>
>> >> On Mon, Jan 14, 2013 at 9:40 PM, Marcel Kinard <cm...@gmail.com>
>> wrote:
>> >>
>> >>> Sorry if this got asked before, but does a feature branch get deleted
>> >>> after it is merged? Just wondering about branch clutter over a long
>> period,
>> >>> or if this is just the same as a topic branch using today's committer
>> >>> workflow.
>> >>>
>> >>>
>> >>> On 1/14/2013 5:34 PM, Brian LeRoux wrote:
>> >>>
>> >>>> You work on a Feature branch. It gets rolled into Dev as needed so
>> >>>> others can merge / collaborate on said feature. When it feels right
>> >>>> instead of merging a large set of potentially breaking commits to
>> >>>> Unstable the dev working on said feature just merges that feature.
>> >>>> This would require more responsibility for the committer to keep track
>> >>>> of their feature branches which I could see as being more overhead.
>> >>>
>>
Re: too long to package a release?
Posted by Filip Maj <fi...@adobe.com>.
I was the one who didn't want to sign up for G+ :)
Now it's a moot point as my gramma uses it and so, by proxy, I am required
to as well :P
On 1/15/13 6:22 AM, "Michal Mocny" <mm...@chromium.org> wrote:
>Thanks for coordinating schedules Brain. Im quite glad to be on EST :)
>
>We should also establish a medium: Google hangouts were not well received
>by everyone last year, (not everyone had a G+ account), but I cannot think
>of anything that is nearly as convenient. Suggestions?
>
>-Michal
>
>
>On Tue, Jan 15, 2013 at 7:52 AM, Becky Gibson
><gi...@gmail.com>wrote:
>
>> Am I correct in assuming US pacific time zone?
>>
>> Sent from my iPad
>>
>> On Jan 15, 2013, at 4:36 AM, Brian LeRoux <b...@brian.io> wrote:
>>
>> > Works for me, however, to accommodate EU community we must to consider
>> > times unholy. This is Apache Way from what I understand.
>> >
>> > I created a form to help us pick a time to talk.
>> >
>> > http://goo.gl/h9d1a
>> >
>> >
>> >
>> > On Mon, Jan 14, 2013 at 7:06 PM, Michal Mocny <mm...@chromium.org>
>> wrote:
>> >> Okay gentlemen, I think there have been countless good points made
>>from
>> all
>> >> parties, but also some bike-shedding.
>> >>
>> >> Perhaps it is time to schedule some face-time to better articulate
>>some
>> of
>> >> the finer points, and to help come to some consensus?
>> >>
>> >> -Michal
>> >>
>> >>
>> >> On Mon, Jan 14, 2013 at 9:40 PM, Marcel Kinard <cm...@gmail.com>
>> wrote:
>> >>
>> >>> Sorry if this got asked before, but does a feature branch get
>>deleted
>> >>> after it is merged? Just wondering about branch clutter over a long
>> period,
>> >>> or if this is just the same as a topic branch using today's
>>committer
>> >>> workflow.
>> >>>
>> >>>
>> >>> On 1/14/2013 5:34 PM, Brian LeRoux wrote:
>> >>>
>> >>>> You work on a Feature branch. It gets rolled into Dev as needed so
>> >>>> others can merge / collaborate on said feature. When it feels right
>> >>>> instead of merging a large set of potentially breaking commits to
>> >>>> Unstable the dev working on said feature just merges that feature.
>> >>>> This would require more responsibility for the committer to keep
>>track
>> >>>> of their feature branches which I could see as being more overhead.
>> >>>
>>
Re: too long to package a release?
Posted by Michal Mocny <mm...@chromium.org>.
Thanks for coordinating schedules Brain. Im quite glad to be on EST :)
We should also establish a medium: Google hangouts were not well received
by everyone last year, (not everyone had a G+ account), but I cannot think
of anything that is nearly as convenient. Suggestions?
-Michal
On Tue, Jan 15, 2013 at 7:52 AM, Becky Gibson <gi...@gmail.com>wrote:
> Am I correct in assuming US pacific time zone?
>
> Sent from my iPad
>
> On Jan 15, 2013, at 4:36 AM, Brian LeRoux <b...@brian.io> wrote:
>
> > Works for me, however, to accommodate EU community we must to consider
> > times unholy. This is Apache Way from what I understand.
> >
> > I created a form to help us pick a time to talk.
> >
> > http://goo.gl/h9d1a
> >
> >
> >
> > On Mon, Jan 14, 2013 at 7:06 PM, Michal Mocny <mm...@chromium.org>
> wrote:
> >> Okay gentlemen, I think there have been countless good points made from
> all
> >> parties, but also some bike-shedding.
> >>
> >> Perhaps it is time to schedule some face-time to better articulate some
> of
> >> the finer points, and to help come to some consensus?
> >>
> >> -Michal
> >>
> >>
> >> On Mon, Jan 14, 2013 at 9:40 PM, Marcel Kinard <cm...@gmail.com>
> wrote:
> >>
> >>> Sorry if this got asked before, but does a feature branch get deleted
> >>> after it is merged? Just wondering about branch clutter over a long
> period,
> >>> or if this is just the same as a topic branch using today's committer
> >>> workflow.
> >>>
> >>>
> >>> On 1/14/2013 5:34 PM, Brian LeRoux wrote:
> >>>
> >>>> You work on a Feature branch. It gets rolled into Dev as needed so
> >>>> others can merge / collaborate on said feature. When it feels right
> >>>> instead of merging a large set of potentially breaking commits to
> >>>> Unstable the dev working on said feature just merges that feature.
> >>>> This would require more responsibility for the committer to keep track
> >>>> of their feature branches which I could see as being more overhead.
> >>>
>
Re: too long to package a release?
Posted by Becky Gibson <gi...@gmail.com>.
Am I correct in assuming US pacific time zone?
Sent from my iPad
On Jan 15, 2013, at 4:36 AM, Brian LeRoux <b...@brian.io> wrote:
> Works for me, however, to accommodate EU community we must to consider
> times unholy. This is Apache Way from what I understand.
>
> I created a form to help us pick a time to talk.
>
> http://goo.gl/h9d1a
>
>
>
> On Mon, Jan 14, 2013 at 7:06 PM, Michal Mocny <mm...@chromium.org> wrote:
>> Okay gentlemen, I think there have been countless good points made from all
>> parties, but also some bike-shedding.
>>
>> Perhaps it is time to schedule some face-time to better articulate some of
>> the finer points, and to help come to some consensus?
>>
>> -Michal
>>
>>
>> On Mon, Jan 14, 2013 at 9:40 PM, Marcel Kinard <cm...@gmail.com> wrote:
>>
>>> Sorry if this got asked before, but does a feature branch get deleted
>>> after it is merged? Just wondering about branch clutter over a long period,
>>> or if this is just the same as a topic branch using today's committer
>>> workflow.
>>>
>>>
>>> On 1/14/2013 5:34 PM, Brian LeRoux wrote:
>>>
>>>> You work on a Feature branch. It gets rolled into Dev as needed so
>>>> others can merge / collaborate on said feature. When it feels right
>>>> instead of merging a large set of potentially breaking commits to
>>>> Unstable the dev working on said feature just merges that feature.
>>>> This would require more responsibility for the committer to keep track
>>>> of their feature branches which I could see as being more overhead.
>>>
Re: too long to package a release?
Posted by Brian LeRoux <b...@brian.io>.
Works for me, however, to accommodate EU community we must to consider
times unholy. This is Apache Way from what I understand.
I created a form to help us pick a time to talk.
http://goo.gl/h9d1a
On Mon, Jan 14, 2013 at 7:06 PM, Michal Mocny <mm...@chromium.org> wrote:
> Okay gentlemen, I think there have been countless good points made from all
> parties, but also some bike-shedding.
>
> Perhaps it is time to schedule some face-time to better articulate some of
> the finer points, and to help come to some consensus?
>
> -Michal
>
>
> On Mon, Jan 14, 2013 at 9:40 PM, Marcel Kinard <cm...@gmail.com> wrote:
>
>> Sorry if this got asked before, but does a feature branch get deleted
>> after it is merged? Just wondering about branch clutter over a long period,
>> or if this is just the same as a topic branch using today's committer
>> workflow.
>>
>>
>> On 1/14/2013 5:34 PM, Brian LeRoux wrote:
>>
>>> You work on a Feature branch. It gets rolled into Dev as needed so
>>> others can merge / collaborate on said feature. When it feels right
>>> instead of merging a large set of potentially breaking commits to
>>> Unstable the dev working on said feature just merges that feature.
>>> This would require more responsibility for the committer to keep track
>>> of their feature branches which I could see as being more overhead.
>>>
>>>
>>
Re: too long to package a release?
Posted by Michal Mocny <mm...@chromium.org>.
Okay gentlemen, I think there have been countless good points made from all
parties, but also some bike-shedding.
Perhaps it is time to schedule some face-time to better articulate some of
the finer points, and to help come to some consensus?
-Michal
On Mon, Jan 14, 2013 at 9:40 PM, Marcel Kinard <cm...@gmail.com> wrote:
> Sorry if this got asked before, but does a feature branch get deleted
> after it is merged? Just wondering about branch clutter over a long period,
> or if this is just the same as a topic branch using today's committer
> workflow.
>
>
> On 1/14/2013 5:34 PM, Brian LeRoux wrote:
>
>> You work on a Feature branch. It gets rolled into Dev as needed so
>> others can merge / collaborate on said feature. When it feels right
>> instead of merging a large set of potentially breaking commits to
>> Unstable the dev working on said feature just merges that feature.
>> This would require more responsibility for the committer to keep track
>> of their feature branches which I could see as being more overhead.
>>
>>
>
Re: too long to package a release?
Posted by Marcel Kinard <cm...@gmail.com>.
Sorry if this got asked before, but does a feature branch get deleted
after it is merged? Just wondering about branch clutter over a long
period, or if this is just the same as a topic branch using today's
committer workflow.
On 1/14/2013 5:34 PM, Brian LeRoux wrote:
> You work on a Feature branch. It gets rolled into Dev as needed so
> others can merge / collaborate on said feature. When it feels right
> instead of merging a large set of potentially breaking commits to
> Unstable the dev working on said feature just merges that feature.
> This would require more responsibility for the committer to keep track
> of their feature branches which I could see as being more overhead.
>
Re: too long to package a release?
Posted by Filip Maj <fi...@adobe.com>.
>My ideal here is to get to a point where there is something, whatever
>it is, that we want to denote as a release. That something should not
>require a whole bunch of coordination. There should be a working
>branch, whatever we call it, ready for a tag and nothing else on any
>arbitrary date to be considered a release. Does that make sense?
This is the goal we should have in mind for this discussion. So, agreed
and yes, does make sense :)
I would also prefer to stay away from cherry-picking as much as possible.
Re: too long to package a release?
Posted by Brian LeRoux <b...@brian.io>.
I think its basically the same except cherry picking not necessary.
(But I've been known to be very wrong so take that with a grain of
salt!)
You work on a Feature branch. It gets rolled into Dev as needed so
others can merge / collaborate on said feature. When it feels right
instead of merging a large set of potentially breaking commits to
Unstable the dev working on said feature just merges that feature.
This would require more responsibility for the committer to keep track
of their feature branches which I could see as being more overhead.
My ideal here is to get to a point where there is something, whatever
it is, that we want to denote as a release. That something should not
require a whole bunch of coordination. There should be a working
branch, whatever we call it, ready for a tag and nothing else on any
arbitrary date to be considered a release. Does that make sense?
On Mon, Jan 14, 2013 at 2:18 PM, Andrew Grieve <ag...@chromium.org> wrote:
> Could you elaborate on what the workflow would be if we merged only from
> Feature branches?
>
> On Mon, Jan 14, 2013 at 5:14 PM, Brian LeRoux <b...@brian.io> wrote:
>
>> So, what if Canonical branches only received merges from Feature
>> branches...?
>>
>> On Mon, Jan 14, 2013 at 2:02 PM, Andrew Grieve <ag...@chromium.org>
>> wrote:
>> > On Mon, Jan 14, 2013 at 4:54 PM, Filip Maj <fi...@adobe.com> wrote:
>> >
>> >>
>> >> >But do Canonical branches merge into each other? I'm thinking no.
>> >>
>> >> My understanding:
>> >>
>> >> - work goes into feature branches
>> >> - when contributor(s) deem feature is ready, merge into Unstable, which
>> >> then gets vetted (test!!!!!)
>> >> - at some point unstable merges into Next
>> >> - when tagging, we merge Next into Stable and tag
>> >>
>> >
>> > That's my understanding as well.
>> >
>> > The "At some point" part would be when we say "hey, let's start working
>> on
>> > cutting a release", which should align with the wiki's
>> > RoadMap<http://wiki.apache.org/cordova/RoadmapProjects> (which
>> > targeted 2.3 for November, whoops!).
>> >
>> >
>> >>
>> >> Would be different for bug fixes or other maintenance-type commits too,
>> >> ya? Those would be directly into Next.
>> >>
>> > It might cause headaches to commit bug-fixes into Next when it comes time
>> > to merge Unstable -> Next.
>> >
>> >
>> >>
>> >> Finally, what about hot fixes / patch releases? Branch off the tag in
>> >> Stable and put hot patch work into there?
>> >>
>> > Agree. I think the flow here should be to commit change to Unstable and
>> > then cherry-pick it into a branch off the tag (when feasible).
>>
Re: too long to package a release?
Posted by Marcel Kinard <cm...@gmail.com>.
Shawn, be aware that there are separate git repos for Windows desktop 8,
WP7, and WP8.
On 1/14/2013 5:33 PM, Shawn Wildermuth wrote:
> - Upgrade it to support WP8
Re: too long to package a release?
Posted by Brian LeRoux <b...@brian.io>.
Hey shawn, feel free to kick up a new thread about Windows Phone dev.
We'd love your help. You can read how we'd like you to work w/ us
here:
http://wiki.apache.org/cordova/ContributorWorkflow
On Mon, Jan 14, 2013 at 2:33 PM, Shawn Wildermuth
<sh...@agilitrain.com> wrote:
> Anyone actively working on the Windows Phone template and library? I am
> happy to pitch in but don't want to step on toes. I would like to:
>
> - Improve the template eliminating opening pivoting animation.
> - Upgrade it to support WP8
> - Fix some issues with opening external links and phone links in the
> library.
>
> Can I proceed?
>
> - stw
>
> I don't even use spell check - my misspellings are on purpose.
>
>
RE: too long to package a release?
Posted by Shawn Wildermuth <sh...@agilitrain.com>.
Anyone actively working on the Windows Phone template and library? I am
happy to pitch in but don't want to step on toes. I would like to:
- Improve the template eliminating opening pivoting animation.
- Upgrade it to support WP8
- Fix some issues with opening external links and phone links in the
library.
Can I proceed?
- stw
I don't even use spell check - my misspellings are on purpose.
Re: too long to package a release?
Posted by Braden Shepherdson <br...@chromium.org>.
Andrew beat me to it. I don't see how feature branches can be practical. We
would have to keep track of all the feature branches on the server, and
their current merged state.
I think it makes sense for all new commits to go into unstable, whether
they be urgent bug fixes or new features or whatever. If the bug fix is
needed for a point release, it can be cherrypicked from unstable to the
point release's branch (skipping the others canonical branches), and then
the fix will be in the next {merge to next, merge to stable, full release}
as well, with no special effort.
As long as the flow always goes unstable -> next -> stable, there are no
problems. Cherrypicking into point release branches is safe, since those
are never merged in and no canonical branches are ever merged to them (or
else they wouldn't actually be point releases). There are no cycles in this
graph.
On Mon, Jan 14, 2013 at 5:18 PM, Andrew Grieve <ag...@chromium.org> wrote:
> Could you elaborate on what the workflow would be if we merged only from
> Feature branches?
>
> On Mon, Jan 14, 2013 at 5:14 PM, Brian LeRoux <b...@brian.io> wrote:
>
> > So, what if Canonical branches only received merges from Feature
> > branches...?
> >
> > On Mon, Jan 14, 2013 at 2:02 PM, Andrew Grieve <ag...@chromium.org>
> > wrote:
> > > On Mon, Jan 14, 2013 at 4:54 PM, Filip Maj <fi...@adobe.com> wrote:
> > >
> > >>
> > >> >But do Canonical branches merge into each other? I'm thinking no.
> > >>
> > >> My understanding:
> > >>
> > >> - work goes into feature branches
> > >> - when contributor(s) deem feature is ready, merge into Unstable,
> which
> > >> then gets vetted (test!!!!!)
> > >> - at some point unstable merges into Next
> > >> - when tagging, we merge Next into Stable and tag
> > >>
> > >
> > > That's my understanding as well.
> > >
> > > The "At some point" part would be when we say "hey, let's start working
> > on
> > > cutting a release", which should align with the wiki's
> > > RoadMap<http://wiki.apache.org/cordova/RoadmapProjects> (which
> > > targeted 2.3 for November, whoops!).
> > >
> > >
> > >>
> > >> Would be different for bug fixes or other maintenance-type commits
> too,
> > >> ya? Those would be directly into Next.
> > >>
> > > It might cause headaches to commit bug-fixes into Next when it comes
> time
> > > to merge Unstable -> Next.
> > >
> > >
> > >>
> > >> Finally, what about hot fixes / patch releases? Branch off the tag in
> > >> Stable and put hot patch work into there?
> > >>
> > > Agree. I think the flow here should be to commit change to Unstable and
> > > then cherry-pick it into a branch off the tag (when feasible).
> >
>
Re: too long to package a release?
Posted by Andrew Grieve <ag...@chromium.org>.
Could you elaborate on what the workflow would be if we merged only from
Feature branches?
On Mon, Jan 14, 2013 at 5:14 PM, Brian LeRoux <b...@brian.io> wrote:
> So, what if Canonical branches only received merges from Feature
> branches...?
>
> On Mon, Jan 14, 2013 at 2:02 PM, Andrew Grieve <ag...@chromium.org>
> wrote:
> > On Mon, Jan 14, 2013 at 4:54 PM, Filip Maj <fi...@adobe.com> wrote:
> >
> >>
> >> >But do Canonical branches merge into each other? I'm thinking no.
> >>
> >> My understanding:
> >>
> >> - work goes into feature branches
> >> - when contributor(s) deem feature is ready, merge into Unstable, which
> >> then gets vetted (test!!!!!)
> >> - at some point unstable merges into Next
> >> - when tagging, we merge Next into Stable and tag
> >>
> >
> > That's my understanding as well.
> >
> > The "At some point" part would be when we say "hey, let's start working
> on
> > cutting a release", which should align with the wiki's
> > RoadMap<http://wiki.apache.org/cordova/RoadmapProjects> (which
> > targeted 2.3 for November, whoops!).
> >
> >
> >>
> >> Would be different for bug fixes or other maintenance-type commits too,
> >> ya? Those would be directly into Next.
> >>
> > It might cause headaches to commit bug-fixes into Next when it comes time
> > to merge Unstable -> Next.
> >
> >
> >>
> >> Finally, what about hot fixes / patch releases? Branch off the tag in
> >> Stable and put hot patch work into there?
> >>
> > Agree. I think the flow here should be to commit change to Unstable and
> > then cherry-pick it into a branch off the tag (when feasible).
>
Re: too long to package a release?
Posted by Brian LeRoux <b...@brian.io>.
So, what if Canonical branches only received merges from Feature branches...?
On Mon, Jan 14, 2013 at 2:02 PM, Andrew Grieve <ag...@chromium.org> wrote:
> On Mon, Jan 14, 2013 at 4:54 PM, Filip Maj <fi...@adobe.com> wrote:
>
>>
>> >But do Canonical branches merge into each other? I'm thinking no.
>>
>> My understanding:
>>
>> - work goes into feature branches
>> - when contributor(s) deem feature is ready, merge into Unstable, which
>> then gets vetted (test!!!!!)
>> - at some point unstable merges into Next
>> - when tagging, we merge Next into Stable and tag
>>
>
> That's my understanding as well.
>
> The "At some point" part would be when we say "hey, let's start working on
> cutting a release", which should align with the wiki's
> RoadMap<http://wiki.apache.org/cordova/RoadmapProjects> (which
> targeted 2.3 for November, whoops!).
>
>
>>
>> Would be different for bug fixes or other maintenance-type commits too,
>> ya? Those would be directly into Next.
>>
> It might cause headaches to commit bug-fixes into Next when it comes time
> to merge Unstable -> Next.
>
>
>>
>> Finally, what about hot fixes / patch releases? Branch off the tag in
>> Stable and put hot patch work into there?
>>
> Agree. I think the flow here should be to commit change to Unstable and
> then cherry-pick it into a branch off the tag (when feasible).
Re: too long to package a release?
Posted by Andrew Grieve <ag...@chromium.org>.
On Mon, Jan 14, 2013 at 4:54 PM, Filip Maj <fi...@adobe.com> wrote:
>
> >But do Canonical branches merge into each other? I'm thinking no.
>
> My understanding:
>
> - work goes into feature branches
> - when contributor(s) deem feature is ready, merge into Unstable, which
> then gets vetted (test!!!!!)
> - at some point unstable merges into Next
> - when tagging, we merge Next into Stable and tag
>
That's my understanding as well.
The "At some point" part would be when we say "hey, let's start working on
cutting a release", which should align with the wiki's
RoadMap<http://wiki.apache.org/cordova/RoadmapProjects> (which
targeted 2.3 for November, whoops!).
>
> Would be different for bug fixes or other maintenance-type commits too,
> ya? Those would be directly into Next.
>
It might cause headaches to commit bug-fixes into Next when it comes time
to merge Unstable -> Next.
>
> Finally, what about hot fixes / patch releases? Branch off the tag in
> Stable and put hot patch work into there?
>
Agree. I think the flow here should be to commit change to Unstable and
then cherry-pick it into a branch off the tag (when feasible).
Re: too long to package a release?
Posted by Filip Maj <fi...@adobe.com>.
>But do Canonical branches merge into each other? I'm thinking no.
My understanding:
- work goes into feature branches
- when contributor(s) deem feature is ready, merge into Unstable, which
then gets vetted (test!!!!!)
- at some point unstable merges into Next
- when tagging, we merge Next into Stable and tag
Would be different for bug fixes or other maintenance-type commits too,
ya? Those would be directly into Next.
Finally, what about hot fixes / patch releases? Branch off the tag in
Stable and put hot patch work into there?
Re: too long to package a release?
Posted by Brian LeRoux <b...@brian.io>.
Ok. Lets go at this from a workflow perspective. One thing I'd like to
note is the two classifications of branch.
There are canonical branches:
- Dev (or Master)
- Unstable (or Next)
- Stable
And then there are feature branches.
Feature branches merge into Canonical branches as appropriate. But do
Canonical branches merge into each other? I'm thinking no. But want to
hear what ppl think. I feel this might be our source of collective
confusion.
Re: too long to package a release?
Posted by Filip Maj <fi...@adobe.com>.
I think we all agree on the general flow of feature branch -> "staging" ->
merge into "master" + tag.
Ripple uses "next" as the label for the branch with all stuff going into
the next release. I like this approach.
On 1/11/13 7:48 AM, "Andrew Grieve" <ag...@chromium.org> wrote:
>I don't think there's any advantage to creating them ahead of time, so we
>might as well not bother.
>
>
>On Fri, Jan 11, 2013 at 10:32 AM, Braden Shepherdson
><br...@chromium.org>wrote:
>
>> Maybe I'm being coloured by the Chrome channels, but it seems to me
>>that we
>> would be doing our "development" of the next release in "dev", rather
>>than
>> unstable, and that bleeding edge Cordova users wanting the latest
>>features
>> with no outright breakages but with higher possibility of bugs should
>>use
>> "unstable". But I'm not sure how and when changes would move from one to
>> the other, whichever way around the names go. I'm imagining the flow
>>would
>> be:
>> Feature branches ---ready to push--> my "dev" (your "unstable")
>> ---release candidate--> my "unstable" (your "dev") ---release-->
>> stable, tagged.
>>
>> Are we going to have branches for each minor release (ie. 2.3, 2.4) so
>>that
>> we can do point releases on them? Or would those be created only as
>> necessary when we needed a point release?
>>
>>
>> On Thu, Jan 10, 2013 at 9:05 PM, Andrew Grieve <ag...@chromium.org>
>> wrote:
>>
>> > I'm not clear on the difference between dev and unstable. If
>>something is
>> > so shaky that we're considering not putting it in the next release,
>>then
>> > I'd think that would go on a named feature branch (e.g.
>>array_buffers).
>> >
>> > Unless... is the purpose of dev to be where we put together a release
>> > candidate? If so, maybe a better name would be "staging"
>> >
>> >
>> > On Thu, Jan 10, 2013 at 8:13 PM, Filip Maj <fi...@adobe.com> wrote:
>> >
>> > > On 1/10/13 5:07 PM, "Brian LeRoux" <b...@brian.io> wrote:
>> > >
>> > > >Thank you. I lean to agreement w/ Andrew that more meaningful pull
>> > > >reqs are better and having named branches for what they do makes
>> > > >sense. Also agree that tags are for points in time---but I take no
>> > > >exception to a branch for those as well for dev purposes.
>> > > >
>> > > >Let me try to capture the conversation to this point:
>> > > >
>> > > >Branches:
>> > > >- Master gets deleted. We want meaningful pull requests and this
>>will
>> > > >force folks to pick a branch to dev against.
>> > > >- Stable: This is stable and frozen on the last tagged release.
>> > > >- Dev: The next release to be tagged. Feature branches merged from
>> > > >master when confident. This should build cleanly.
>> > >
>> > > ^^ merged from master?
>> > >
>> > > >- Unstable: the current working branch. Feature branches merged as
>> > > >needed for collaboration. No guarantee it builds.
>> > > >
>> > > >Tags:
>> > > >- Happen on the Stable branch.
>> > > >
>> > > >Workflow
>> > > >- Everyone works from local feature branch rebasing and committing
>>to
>> > > >Unstable as neccessary.
>> > > >- When that feature branch is considered good enough, it is merged
>> into
>> > > >Dev.
>> > > >- On release date whatever is Dev is rebased to Stable. Tagged.
>> > Released.
>> > > >
>> > > >Thoughts?
>> > >
>> > >
>> >
>>
Re: too long to package a release?
Posted by Andrew Grieve <ag...@chromium.org>.
I don't think there's any advantage to creating them ahead of time, so we
might as well not bother.
On Fri, Jan 11, 2013 at 10:32 AM, Braden Shepherdson <br...@chromium.org>wrote:
> Maybe I'm being coloured by the Chrome channels, but it seems to me that we
> would be doing our "development" of the next release in "dev", rather than
> unstable, and that bleeding edge Cordova users wanting the latest features
> with no outright breakages but with higher possibility of bugs should use
> "unstable". But I'm not sure how and when changes would move from one to
> the other, whichever way around the names go. I'm imagining the flow would
> be:
> Feature branches ---ready to push--> my "dev" (your "unstable")
> ---release candidate--> my "unstable" (your "dev") ---release-->
> stable, tagged.
>
> Are we going to have branches for each minor release (ie. 2.3, 2.4) so that
> we can do point releases on them? Or would those be created only as
> necessary when we needed a point release?
>
>
> On Thu, Jan 10, 2013 at 9:05 PM, Andrew Grieve <ag...@chromium.org>
> wrote:
>
> > I'm not clear on the difference between dev and unstable. If something is
> > so shaky that we're considering not putting it in the next release, then
> > I'd think that would go on a named feature branch (e.g. array_buffers).
> >
> > Unless... is the purpose of dev to be where we put together a release
> > candidate? If so, maybe a better name would be "staging"
> >
> >
> > On Thu, Jan 10, 2013 at 8:13 PM, Filip Maj <fi...@adobe.com> wrote:
> >
> > > On 1/10/13 5:07 PM, "Brian LeRoux" <b...@brian.io> wrote:
> > >
> > > >Thank you. I lean to agreement w/ Andrew that more meaningful pull
> > > >reqs are better and having named branches for what they do makes
> > > >sense. Also agree that tags are for points in time---but I take no
> > > >exception to a branch for those as well for dev purposes.
> > > >
> > > >Let me try to capture the conversation to this point:
> > > >
> > > >Branches:
> > > >- Master gets deleted. We want meaningful pull requests and this will
> > > >force folks to pick a branch to dev against.
> > > >- Stable: This is stable and frozen on the last tagged release.
> > > >- Dev: The next release to be tagged. Feature branches merged from
> > > >master when confident. This should build cleanly.
> > >
> > > ^^ merged from master?
> > >
> > > >- Unstable: the current working branch. Feature branches merged as
> > > >needed for collaboration. No guarantee it builds.
> > > >
> > > >Tags:
> > > >- Happen on the Stable branch.
> > > >
> > > >Workflow
> > > >- Everyone works from local feature branch rebasing and committing to
> > > >Unstable as neccessary.
> > > >- When that feature branch is considered good enough, it is merged
> into
> > > >Dev.
> > > >- On release date whatever is Dev is rebased to Stable. Tagged.
> > Released.
> > > >
> > > >Thoughts?
> > >
> > >
> >
>
Re: too long to package a release?
Posted by Braden Shepherdson <br...@chromium.org>.
Maybe I'm being coloured by the Chrome channels, but it seems to me that we
would be doing our "development" of the next release in "dev", rather than
unstable, and that bleeding edge Cordova users wanting the latest features
with no outright breakages but with higher possibility of bugs should use
"unstable". But I'm not sure how and when changes would move from one to
the other, whichever way around the names go. I'm imagining the flow would
be:
Feature branches ---ready to push--> my "dev" (your "unstable")
---release candidate--> my "unstable" (your "dev") ---release-->
stable, tagged.
Are we going to have branches for each minor release (ie. 2.3, 2.4) so that
we can do point releases on them? Or would those be created only as
necessary when we needed a point release?
On Thu, Jan 10, 2013 at 9:05 PM, Andrew Grieve <ag...@chromium.org> wrote:
> I'm not clear on the difference between dev and unstable. If something is
> so shaky that we're considering not putting it in the next release, then
> I'd think that would go on a named feature branch (e.g. array_buffers).
>
> Unless... is the purpose of dev to be where we put together a release
> candidate? If so, maybe a better name would be "staging"
>
>
> On Thu, Jan 10, 2013 at 8:13 PM, Filip Maj <fi...@adobe.com> wrote:
>
> > On 1/10/13 5:07 PM, "Brian LeRoux" <b...@brian.io> wrote:
> >
> > >Thank you. I lean to agreement w/ Andrew that more meaningful pull
> > >reqs are better and having named branches for what they do makes
> > >sense. Also agree that tags are for points in time---but I take no
> > >exception to a branch for those as well for dev purposes.
> > >
> > >Let me try to capture the conversation to this point:
> > >
> > >Branches:
> > >- Master gets deleted. We want meaningful pull requests and this will
> > >force folks to pick a branch to dev against.
> > >- Stable: This is stable and frozen on the last tagged release.
> > >- Dev: The next release to be tagged. Feature branches merged from
> > >master when confident. This should build cleanly.
> >
> > ^^ merged from master?
> >
> > >- Unstable: the current working branch. Feature branches merged as
> > >needed for collaboration. No guarantee it builds.
> > >
> > >Tags:
> > >- Happen on the Stable branch.
> > >
> > >Workflow
> > >- Everyone works from local feature branch rebasing and committing to
> > >Unstable as neccessary.
> > >- When that feature branch is considered good enough, it is merged into
> > >Dev.
> > >- On release date whatever is Dev is rebased to Stable. Tagged.
> Released.
> > >
> > >Thoughts?
> >
> >
>
Re: too long to package a release?
Posted by Andrew Grieve <ag...@chromium.org>.
I'm not clear on the difference between dev and unstable. If something is
so shaky that we're considering not putting it in the next release, then
I'd think that would go on a named feature branch (e.g. array_buffers).
Unless... is the purpose of dev to be where we put together a release
candidate? If so, maybe a better name would be "staging"
On Thu, Jan 10, 2013 at 8:13 PM, Filip Maj <fi...@adobe.com> wrote:
> On 1/10/13 5:07 PM, "Brian LeRoux" <b...@brian.io> wrote:
>
> >Thank you. I lean to agreement w/ Andrew that more meaningful pull
> >reqs are better and having named branches for what they do makes
> >sense. Also agree that tags are for points in time---but I take no
> >exception to a branch for those as well for dev purposes.
> >
> >Let me try to capture the conversation to this point:
> >
> >Branches:
> >- Master gets deleted. We want meaningful pull requests and this will
> >force folks to pick a branch to dev against.
> >- Stable: This is stable and frozen on the last tagged release.
> >- Dev: The next release to be tagged. Feature branches merged from
> >master when confident. This should build cleanly.
>
> ^^ merged from master?
>
> >- Unstable: the current working branch. Feature branches merged as
> >needed for collaboration. No guarantee it builds.
> >
> >Tags:
> >- Happen on the Stable branch.
> >
> >Workflow
> >- Everyone works from local feature branch rebasing and committing to
> >Unstable as neccessary.
> >- When that feature branch is considered good enough, it is merged into
> >Dev.
> >- On release date whatever is Dev is rebased to Stable. Tagged. Released.
> >
> >Thoughts?
>
>
Re: too long to package a release?
Posted by Filip Maj <fi...@adobe.com>.
On 1/10/13 5:07 PM, "Brian LeRoux" <b...@brian.io> wrote:
>Thank you. I lean to agreement w/ Andrew that more meaningful pull
>reqs are better and having named branches for what they do makes
>sense. Also agree that tags are for points in time---but I take no
>exception to a branch for those as well for dev purposes.
>
>Let me try to capture the conversation to this point:
>
>Branches:
>- Master gets deleted. We want meaningful pull requests and this will
>force folks to pick a branch to dev against.
>- Stable: This is stable and frozen on the last tagged release.
>- Dev: The next release to be tagged. Feature branches merged from
>master when confident. This should build cleanly.
^^ merged from master?
>- Unstable: the current working branch. Feature branches merged as
>needed for collaboration. No guarantee it builds.
>
>Tags:
>- Happen on the Stable branch.
>
>Workflow
>- Everyone works from local feature branch rebasing and committing to
>Unstable as neccessary.
>- When that feature branch is considered good enough, it is merged into
>Dev.
>- On release date whatever is Dev is rebased to Stable. Tagged. Released.
>
>Thoughts?
Re: too long to package a release?
Posted by Brian LeRoux <b...@brian.io>.
Thank you. I lean to agreement w/ Andrew that more meaningful pull
reqs are better and having named branches for what they do makes
sense. Also agree that tags are for points in time---but I take no
exception to a branch for those as well for dev purposes.
Let me try to capture the conversation to this point:
Branches:
- Master gets deleted. We want meaningful pull requests and this will
force folks to pick a branch to dev against.
- Stable: This is stable and frozen on the last tagged release.
- Dev: The next release to be tagged. Feature branches merged from
master when confident. This should build cleanly.
- Unstable: the current working branch. Feature branches merged as
needed for collaboration. No guarantee it builds.
Tags:
- Happen on the Stable branch.
Workflow
- Everyone works from local feature branch rebasing and committing to
Unstable as neccessary.
- When that feature branch is considered good enough, it is merged into Dev.
- On release date whatever is Dev is rebased to Stable. Tagged. Released.
Thoughts?
On Thu, Jan 10, 2013 at 7:02 AM, Marcel Kinard <cm...@gmail.com> wrote:
> Poking this thread. So is there consensus on how to do this? If so, can this
> be summarized and written up, perhaps on the ContributorWorkflow /
> CommiterWorkflow wiki pages?
>
> And when would we want to start operating with this, 2.4/now or later?
>
> -- Marcel Kinard
Re: too long to package a release?
Posted by Marcel Kinard <cm...@gmail.com>.
Poking this thread. So is there consensus on how to do this? If so, can
this be summarized and written up, perhaps on the ContributorWorkflow /
CommiterWorkflow wiki pages?
And when would we want to start operating with this, 2.4/now or later?
-- Marcel Kinard
Re: too long to package a release?
Posted by Michal Mocny <mm...@chromium.org>.
On Thu, Jan 3, 2013 at 9:43 AM, Andrew Grieve <ag...@chromium.org> wrote:
> On Wed, Jan 2, 2013 at 11:05 PM, Michal Mocny <mm...@chromium.org> wrote:
>
> > On Wed, Jan 2, 2013 at 7:27 PM, Andrew Grieve <ag...@chromium.org>
> > wrote:
> >
> > > From my understanding of git, there's nothing special about the master
> > > branch, except that it's what gets checked out when someone doesn't
> > > explicitly say which branch they want.
> > >
> > > Joe pointed out that sometimes random people check out the code and
> > expect
> > > it to be stable.
> > > Gord pointed out that people tend to submit pull requests assuming that
> > > master == dev branch.
> > >
> > > I think choosing between these two data points, I'd lean towards having
> > > people submit more useful pull requests.
> > >
> > Well put, agreed.
> >
> >
> > >
> > > I don't think either option affects how you'd go about doing a point
> > > release. You would:
> > > 1. Check out the relevant release tag (e.g. 2.3.0)
> > > 2. Give the branch a name (e.g. branch_2.3.1)
> > >
> > I'm not sure why you would name the branch after checkout? Wouldn't you
> > name it by tagging after doing the merges in step 3?
> >
>
> When I check out one of our current tags, my branch is "(no branch)". I
> suggest giving it a name right away so that you are able to switch to it
> again.
> $ git checkout 2.2.0
> Note: checking out '2.2.0'.
>
I think that you could just do a "git checkout 2.2" in this case which is
already a branch. "2.2.0" would be a tag of the HEAD of 2.2 branch if that
was the most recent point release.
Otherwise, we would have multiple branches for each point release, on which
no dev should be done except on the most recent one. Also, if bugfixes are
done in feature branches of a release branch, every merge back could be
considered a point release?
>
> You are in 'detached HEAD' state. You can look around, make experimental
> changes and commit them, and you can discard any commits you make in this
> state without impacting any branches by performing another checkout.
>
> If you want to create a new branch to retain commits you create, you may
> do so (now or later) by using -b with the checkout command again. Example:
>
> git checkout -b new_branch_name
>
> HEAD is now at 02b91c5... Version 2.2.0
>
>
> >
> >
> > > 3. Merge in all of the changes that you want to put in the point
> release
> > > (ideally, these would already be committed in the dev branch, be it
> > "next"
> > > or "master").
> > > 4. Tag the release.
> > >
> > >
> > > On Wed, Jan 2, 2013 at 5:11 PM, Gord Tanner <gt...@gmail.com> wrote:
> > >
> > > > 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 <gt...@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 <mm...@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 <gt...@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 <fi...@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" <bo...@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 <fi...@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
> > > > >> >> > >>>>>>><ag...@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
> > > > >> >> > >>>>>>>><cm...@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
> > > > >> >> > >>>>>>>> >
> > > > >> >> > >>>>>>>>
> > > > >> >> > >>
> > > > >> >> >
> > > > >> >> >
> > > > >> >>
> > > > >> >
> > > > >> >
> > > > >>
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: too long to package a release?
Posted by Andrew Grieve <ag...@chromium.org>.
On Wed, Jan 2, 2013 at 11:05 PM, Michal Mocny <mm...@chromium.org> wrote:
> On Wed, Jan 2, 2013 at 7:27 PM, Andrew Grieve <ag...@chromium.org>
> wrote:
>
> > From my understanding of git, there's nothing special about the master
> > branch, except that it's what gets checked out when someone doesn't
> > explicitly say which branch they want.
> >
> > Joe pointed out that sometimes random people check out the code and
> expect
> > it to be stable.
> > Gord pointed out that people tend to submit pull requests assuming that
> > master == dev branch.
> >
> > I think choosing between these two data points, I'd lean towards having
> > people submit more useful pull requests.
> >
> Well put, agreed.
>
>
> >
> > I don't think either option affects how you'd go about doing a point
> > release. You would:
> > 1. Check out the relevant release tag (e.g. 2.3.0)
> > 2. Give the branch a name (e.g. branch_2.3.1)
> >
> I'm not sure why you would name the branch after checkout? Wouldn't you
> name it by tagging after doing the merges in step 3?
>
When I check out one of our current tags, my branch is "(no branch)". I
suggest giving it a name right away so that you are able to switch to it
again.
$ git checkout 2.2.0
Note: checking out '2.2.0'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:
git checkout -b new_branch_name
HEAD is now at 02b91c5... Version 2.2.0
>
>
> > 3. Merge in all of the changes that you want to put in the point release
> > (ideally, these would already be committed in the dev branch, be it
> "next"
> > or "master").
> > 4. Tag the release.
> >
> >
> > On Wed, Jan 2, 2013 at 5:11 PM, Gord Tanner <gt...@gmail.com> wrote:
> >
> > > 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 <gt...@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 <mm...@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 <mm...@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 <gt...@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 <fi...@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" <bo...@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 <fi...@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
> > > >> >> > >>>>>>><ag...@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
> > > >> >> > >>>>>>>><cm...@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
> > > >> >> > >>>>>>>> >
> > > >> >> > >>>>>>>>
> > > >> >> > >>
> > > >> >> >
> > > >> >> >
> > > >> >>
> > > >> >
> > > >> >
> > > >>
> > > >
> > > >
> > >
> >
>
Re: too long to package a release?
Posted by Michal Mocny <mm...@chromium.org>.
On Wed, Jan 2, 2013 at 7:27 PM, Andrew Grieve <ag...@chromium.org> wrote:
> From my understanding of git, there's nothing special about the master
> branch, except that it's what gets checked out when someone doesn't
> explicitly say which branch they want.
>
> Joe pointed out that sometimes random people check out the code and expect
> it to be stable.
> Gord pointed out that people tend to submit pull requests assuming that
> master == dev branch.
>
> I think choosing between these two data points, I'd lean towards having
> people submit more useful pull requests.
>
Well put, agreed.
>
> I don't think either option affects how you'd go about doing a point
> release. You would:
> 1. Check out the relevant release tag (e.g. 2.3.0)
> 2. Give the branch a name (e.g. branch_2.3.1)
>
I'm not sure why you would name the branch after checkout? Wouldn't you
name it by tagging after doing the merges in step 3?
> 3. Merge in all of the changes that you want to put in the point release
> (ideally, these would already be committed in the dev branch, be it "next"
> or "master").
> 4. Tag the release.
>
>
> On Wed, Jan 2, 2013 at 5:11 PM, Gord Tanner <gt...@gmail.com> wrote:
>
> > 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 <gt...@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 <mm...@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 <mm...@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 <gt...@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 <fi...@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" <bo...@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 <fi...@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
> > >> >> > >>>>>>><ag...@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
> > >> >> > >>>>>>>><cm...@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
> > >> >> > >>>>>>>> >
> > >> >> > >>>>>>>>
> > >> >> > >>
> > >> >> >
> > >> >> >
> > >> >>
> > >> >
> > >> >
> > >>
> > >
> > >
> >
>
Re: too long to package a release?
Posted by Andrew Grieve <ag...@chromium.org>.
>From my understanding of git, there's nothing special about the master
branch, except that it's what gets checked out when someone doesn't
explicitly say which branch they want.
Joe pointed out that sometimes random people check out the code and expect
it to be stable.
Gord pointed out that people tend to submit pull requests assuming that
master == dev branch.
I think choosing between these two data points, I'd lean towards having
people submit more useful pull requests.
I don't think either option affects how you'd go about doing a point
release. You would:
1. Check out the relevant release tag (e.g. 2.3.0)
2. Give the branch a name (e.g. branch_2.3.1)
3. Merge in all of the changes that you want to put in the point release
(ideally, these would already be committed in the dev branch, be it "next"
or "master").
4. Tag the release.
On Wed, Jan 2, 2013 at 5:11 PM, Gord Tanner <gt...@gmail.com> wrote:
> 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 <gt...@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 <mm...@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 <mm...@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 <gt...@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 <fi...@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" <bo...@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 <fi...@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
> >> >> > >>>>>>><ag...@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
> >> >> > >>>>>>>><cm...@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
> >> >> > >>>>>>>> >
> >> >> > >>>>>>>>
> >> >> > >>
> >> >> >
> >> >> >
> >> >>
> >> >
> >> >
> >>
> >
> >
>
Re: too long to package a release?
Posted by Gord Tanner <gt...@gmail.com>.
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 <gt...@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 <mm...@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 <mm...@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 <gt...@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 <fi...@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" <bo...@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 <fi...@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 <bo...@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
>> >> > >>>>>>><ag...@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
>> >> > >>>>>>>><cm...@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
>> >> > >>>>>>>> >
>> >> > >>>>>>>>
>> >> > >>
>> >> >
>> >> >
>> >>
>> >
>> >
>>
>
>
Re: too long to package a release?
Posted by Gord Tanner <gt...@gmail.com>.
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 <mm...@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 <mm...@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 <gt...@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 <fi...@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" <bo...@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 <fi...@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 <bo...@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
> >> > >>>>>>><ag...@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
> >> > >>>>>>>><cm...@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
> >> > >>>>>>>> >
> >> > >>>>>>>>
> >> > >>
> >> >
> >> >
> >>
> >
> >
>
Re: too long to package a release?
Posted by Michal Mocny <mm...@chromium.org>.
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 <mm...@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 <gt...@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 <fi...@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" <bo...@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 <fi...@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 <bo...@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 <bo...@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
>> > >>>>>>><ag...@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
>> > >>>>>>>><cm...@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
>> > >>>>>>>> >
>> > >>>>>>>>
>> > >>
>> >
>> >
>>
>
>
Re: too long to package a release?
Posted by Michal Mocny <mm...@chromium.org>.
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 <gt...@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 <fi...@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" <bo...@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 <fi...@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 <bo...@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 <bo...@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
> > >>>>>>><ag...@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
> > >>>>>>>><cm...@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
> > >>>>>>>> >
> > >>>>>>>>
> > >>
> >
> >
>
Re: too long to package a release?
Posted by Gord Tanner <gt...@gmail.com>.
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 <fi...@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" <bo...@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 <fi...@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 <bo...@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 <bo...@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
> >>>>>>><ag...@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
> >>>>>>>><cm...@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
> >>>>>>>> >
> >>>>>>>>
> >>
>
>
Re: too long to package a release?
Posted by Filip Maj <fi...@adobe.com>.
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" <bo...@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 <fi...@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 <bo...@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 <bo...@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 <mm...@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
>>>>>>><ag...@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
>>>>>>>><cm...@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
>>>>>>>> >
>>>>>>>>
>>
Re: too long to package a release?
Posted by Joe Bowser <bo...@gmail.com>.
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 <fi...@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 <bo...@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 <bo...@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 <mm...@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
>>>>>><ag...@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 <cm...@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
>>>>>>> >
>>>>>>>
>