cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Braden Shepherdson <bra...@chromium.org>
Subject Re: too long to package a release?
Date Tue, 22 Jan 2013 18:59:56 GMT
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 <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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message