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 17:42:48 GMT
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