cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: too long to package a release?
Date Wed, 23 Jan 2013 19:25:37 GMT
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
>><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