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 >
