cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <...@adobe.com>
Subject Re: too long to package a release?
Date Wed, 23 Jan 2013 19:19:59 GMT
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
><braden@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
>> > > >>
>> > > >>
>> > > >
>> > >
>> >
>>


Mime
View raw message