cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <...@adobe.com>
Subject Re: too long to package a release?
Date Fri, 08 Feb 2013 21:56:31 GMT
Awesome! Stoked to see "next" branches dropping for the upcoming 2.5.0rc's
!

On 2/7/13 11:59 AM, "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
View raw message