cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Kinard <cmarc...@gmail.com>
Subject Re: too long to package a release?
Date Fri, 08 Feb 2013 22:22:05 GMT
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
View raw message