cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Becky Gibson <gibson.be...@gmail.com>
Subject Re: too long to package a release?
Date Wed, 20 Feb 2013 18:10:17 GMT
Thank you, Michael!  I do usually go a git push --dry-run to check that I
am pushing what I expect but I'll try the diff as well.


On Wed, Feb 20, 2013 at 1:07 PM, Michal Mocny <mmocny@chromium.org> wrote:

> So there is also http://wiki.apache.org/cordova/CuttingReleases which may
> be useful (esp Taggin section).
>
> As far as the confusion with the two branch names: "topic_branch" is your
> local working branch for a bugfix/feature, and "to_be_merged" is really
> "temporary_new_name_for_a_branch_to_do_rebase_in".  I usually skip that
> step and take the risk or rebasing in topic_branch (aside: this may
> negatively affect diffs if you push updates for a review-edit-re-review
> cycle -- but this isn't an issue for cordova).
>
> Do not checkout 'next' into your master branch.  Update your local branches
> to include the remote next branch (with 'git pull apache' with no branch)
> then you can switch to the next branch locally, apply your patch there, and
> push to that remote branch directly.  Later, merge that commit into master
> locally, and push that.
>
> Do not push to apache next from your local master, or else you will push
> all the changes.
>
> I agree, this is a little confusing, but after a few practice runs it
> should be easy to figure out.  You should probably also check what would be
> pushed with 'git diff apache/[target-branch]' or tag on --stat to that to
> just see that files that would signal a quick "uh-oh".
>
> I'll work to update the wiki later today, and likely others will have more
> tips on how to make sure we don't make mistakes.
>
> -Michal
>
>
>
> On Wed, Feb 20, 2013 at 12:42 PM, Becky Gibson <gibson.becky@gmail.com
> >wrote:
>
> > Can someone please provide a "git cordova release process for dummies"
> > example to make sure I do the release commits and merges properly (the
> > committerWorkflow example didn't help me as I didn't understand the
> > topic_branch and to_be_merged distinction)
> >
> > At any rate, can I do a git checkout apache next into my "master" branch?
> >  Then I can checkout my working_branch,  rebase master (which contains
> the
> > next code) checkout master, merge my fix and push apache next.
> > git checkout apache next
> > git checkout working_branch_with_fix
> > git rebase master
> > git checkout master
> > git merge working_branch_with_fix
> > git push apache next
> >
> > and then repeat this for apache master with the possibility of needing to
> > use -ff when I merge.   Am I on the right track?
> >
> > humbled by git,
> > -becky
> >
> > On Fri, Feb 8, 2013 at 5:22 PM, Marcel Kinard <cmarcelk@gmail.com>
> wrote:
> >
> > > Nice! Thanks, Andrew!
> > >
> > > -- Marcel Kinard
> > >
> > > On Feb 7, 2013, at 2:59 PM, Andrew Grieve <agrieve@chromium.org>
> wrote:
> > >
> > > > The doc's not up-to-date, but I think we ended on consensus for the
> > code
> > > > version. I've taken a stab at updating the wiki pages:
> > > >
> > > > http://wiki.apache.org/cordova/CordovaAndGit  -- Added the idea of
> > > having
> > > > both a master and a next branch
> > > > http://wiki.apache.org/cordova/CommitterWorkflow  -- Added Jesse's
> > > version
> > > > of the "which branch - in code"
> > > > http://wiki.apache.org/cordova/CuttingReleases  -- Changed tagging
> > > > instructions to refer to the "next" branch
> > > >
> > > >
> > > > On Thu, Feb 7, 2013 at 1:26 PM, Marcel Kinard <cmarcelk@gmail.com>
> > > wrote:
> > > >
> > > >> With 2.5 starting, it appears time to poke this thread.
> > > >>
> > > >> - Is the Google doc refreshed with the latest consensus?
> > > >> - If so, should the Google doc be transferred to a wiki page?
> > > >> - Have the necessary branches been created?
> > > >> - Are we all in the boat, and understand how to row this beast?
> > > >>
> > > >> -- Marcel Kinard
> > > >>
> > > >> On Jan 24, 2013, at 5:14 PM, Jesse <purplecabbage@gmail.com> wrote:
> > > >>
> > > >>> Nice Shaz, but I was hoping it was a github style network
> > visualization
> > > >>> that included a few versions worth of merges.
> > > >>> Who wants to draw that?
> > > >>>
> > > >>> On Thu, Jan 24, 2013 at 2:05 PM, Shazron <shazron@gmail.com>
> wrote:
> > > >>>
> > > >>>> Inline image got mangled, here it is linked: http://cl.ly/MOrD
> > > >>>>
> > > >>>>
> > > >>>> On Thu, Jan 24, 2013 at 1:39 PM, Shazron <shazron@gmail.com>
> wrote:
> > > >>>>
> > > >>>>> Thanks for the pseudocode Andrew, seems simpler to understand ;)
> > > >> Jesse's
> > > >>>>> re-factor makes it even easier. Here's my contrib for those more
> > > >> visually
> > > >>>>> inclined:
> > > >>>>>
> > > >>>>>
> > > >>>>> [image: Inline image 2]
> > > >>>>>
> > > >>>>>
> > > >>>>> On Thu, Jan 24, 2013 at 1:29 PM, Andrew Grieve <
> > agrieve@chromium.org
> > > >>> wrote:
> > > >>>>>
> > > >>>>>> Nice! even simpler. :)
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> On Thu, Jan 24, 2013 at 3:44 PM, Jesse <purplecabbage@gmail.com
> >
> > > >> wrote:
> > > >>>>>>
> > > >>>>>>> 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 <
> > > >> agrieve@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 <
> > > >>>>>> braden@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 <
> > purplecabbage@gmail.com>
> > > >>>>>>> wrote:
> > > >>>>>>>>>
> > > >>>>>>>>>> On Thu, Jan 24, 2013 at 11:09 AM, Braden Shepherdson <
> > > >>>>>>>>> braden@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 <
> > > >>>>>>>>>> purplecabbage@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 <
> > > >>>>>> agrieve@chromium.org>
> > > >>>>>>>>> wrote:
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> On Wed, Jan 23, 2013 at 4:58 PM, Michael Brooks <
> > > >>>>>>>>>>> michael@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 <
> 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
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>> --
> > > >>>>>>>>>> @purplecabbage
> > > >>>>>>>>>> risingj.com
> > > >>>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>> --
> > > >>>>>>> @purplecabbage
> > > >>>>>>> risingj.com
> > > >>>>>>>
> > > >>>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>
> > > >>>
> > > >>>
> > > >>> --
> > > >>> @purplecabbage
> > > >>> risingj.com
> > > >>
> > > >>
> > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message