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 <agri...@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 <bra...@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 <purplecabb...@gmail.com> wrote:
> >
> > > On Thu, Jan 24, 2013 at 11:09 AM, Braden Shepherdson <
> > bra...@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 <
> > > purplecabb...@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 <agri...@chromium.org>
> > wrote:
> > > > >
> > > > > On Wed, Jan 23, 2013 at 4:58 PM, Michael Brooks <
> > > > mich...@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 <f...@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" <agri...@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
> > > > > >>>> <bra...@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 <
> > > > > > agri...@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 <
> > > > > > mmo...@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 <
> > > > > > cmarc...@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
