cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse MacFadyen <purplecabb...@gmail.com>
Subject Re: too long to package a release?
Date Thu, 24 Jan 2013 18:57:43 GMT
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
>

Mime
View raw message