cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Braden Shepherdson <bra...@chromium.org>
Subject Re: too long to package a release?
Date Thu, 24 Jan 2013 19:09:47 GMT
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.


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
> >
>

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