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
So there is also http://wiki.apache.org/cordova/CuttingReleases which may
be useful (esp Taggin section).
As far as the confusion with the two branch names: topic_branch is your
local working branch for a bugfix/feature, and to_be_merged is really
temporary_new_name_for_a_branch_to_do_rebase_in.
Thank you, Michael! I do usually go a git push --dry-run to check that I
am pushing what I expect but I'll try the diff as well.
On Wed, Feb 20, 2013 at 1:07 PM, Michal Mocny mmo...@chromium.org wrote:
So there is also http://wiki.apache.org/cordova/CuttingReleases which may
be useful (esp
I didn't know that. Thanks!
On Wed, Feb 20, 2013 at 1:10 PM, Becky Gibson gibson.be...@gmail.comwrote:
Thank you, Michael! I do usually go a git push --dry-run to check that I
am pushing what I expect but I'll try the diff as well.
On Wed, Feb 20, 2013 at 1:07 PM, Michal Mocny
I noticed on iOS the commits going into next are mirrored on master.
For Android that was not done.
What is the correct process?
On 2/20/13 10:12 AM, Michal Mocny mmo...@chromium.org wrote:
I didn't know that. Thanks!
On Wed, Feb 20, 2013 at 1:10 PM, Becky Gibson
Step 5 here: http://wiki.apache.org/cordova/CommitterWorkflow
Probably it should be isFixingRegression instead of isBugFix. I'll
update it now.
On Wed, Feb 20, 2013 at 1:59 PM, Filip Maj f...@adobe.com wrote:
I noticed on iOS the commits going into next are mirrored on master.
For Android
Ok so the flow is: if you are committing into next, always merge into
master. Good. So the CI setup doesn't need to differentiate between master
and next. It can always pull from master.
On 2/20/13 11:04 AM, Andrew Grieve agri...@chromium.org wrote:
Step 5 here:
Honestly, this process is too complex and we should just go back to
what we were doing before. I don't think our git flow was what is
slowing us down.
On Wed, Feb 20, 2013 at 11:22 AM, Filip Maj f...@adobe.com wrote:
Ok so the flow is: if you are committing into next, always merge into
http://cl.ly/MOrD
Master always has all the changes. Next will never have experimental
changes/features after next is created, just bug fixes.
On Wednesday, February 20, 2013, Joe Bowser wrote:
Honestly, this process is too complex and we should just go back to
what we were doing before. I
So when we release a final point release (that is a culmination of rcs,
i.e. 2.5.0rc1-2.5.0rc2-2.5.0), at that point on the next branch
effectively stops being in use.
ASCII graph incoming of potential scenario
Master Branch o--E---o--o--o--o--o--o--o--o
\/ / /
Shaz sums it up perfect. Once we cut 'next' nothing goes in unless its
critical to it being a good release. Anything that goes into next should
almost by definition also go in to master.
Note that this is functionally the same as only ever pushing to master, and
cherry-picking certain commits
Fil - looks right to me.
Added the git commands for committing into next to the wiki:
git checkout next
git pull apache
git checkout topic_branch
git rebase next -i
git checkout next
git merge --ff-only topic_branch
git push apache next
git branch -d topic_branch
git checkout master
git merge
I agree that it is necessary. Just want to make clear that split stream
dev won't speed up the release process (as the thread title implies).
On 2/20/13 11:57 AM, Michal Mocny mmo...@chromium.org wrote:
Also: Fil you are totally correct that this flow only really helps with
split-stream dev, but
Fil: yes, that graph looks correct, with the added note that your rc/final
point release commits are conceptually just tags. Its possible those
also accompany a commit to change some versioning changes in text files,
I'm not sure, but not necessarily.
-Michal
On Wed, Feb 20, 2013 at 2:47 PM,
Also: Fil you are totally correct that this flow only really helps with
split-stream dev, but considering how long it takes and often it happens
(code freeze due to release) this seems kind of necessary. I think it is
also a great foundation for automating packaging and tagging. So lets work
on
Right, that makes sense. In our specific case with all projects having a
VERSION file it should be a commit but I understand your point :)
On 2/20/13 11:55 AM, Michal Mocny mmo...@chromium.org wrote:
Fil: yes, that graph looks correct, with the added note that your rc/final
point release commits
Awesome! Stoked to see next branches dropping for the upcoming 2.5.0rc's
!
On 2/7/13 11:59 AM, Andrew Grieve agri...@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:
Nice! Thanks, Andrew!
-- Marcel Kinard
On Feb 7, 2013, at 2:59 PM, Andrew Grieve agri...@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 --
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
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
On Wed, Jan 23, 2013 at 4:58 PM, Michael Brooks mich...@michaelbrooks.cawrote:
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.
-
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
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,
On Thu, Jan 24, 2013 at 11:09 AM, Braden Shepherdson bra...@chromium.orgwrote:
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
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
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) {
Nice! even simpler. :)
On Thu, Jan 24, 2013 at 3:44 PM, Jesse purplecabb...@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'
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 agri...@chromium.org wrote:
Braden, you're right. I've now done some local playing around in git, and
have
I'm liking it. Start in 2.5?
On Wed, Jan 23, 2013 at 1:19 PM, Filip Maj f...@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
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?
- On Github,
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
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
Talking w/ Dr. David Charles Johnson about this. We think a F2F would
help but before we go that far I think your proposal is close Andrew.
How about firing it into a Google Doc for commenting/and revisioning?
On Tue, Jan 22, 2013 at 12:59 PM, Braden Shepherdson
bra...@chromium.org wrote:
I
Are other committers not from Adobe attending apache con? If so maybe a
meeting in person to discuss this would help.
On 1/22/13 11:52 AM, Brian LeRoux b...@brian.io wrote:
Talking w/ Dr. David Charles Johnson about this. We think a F2F would
help but before we go that far I think your proposal
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
I won't be at ApacheCon. Don't think Michal/Max/Braden had plans to go
either...
On Tue, Jan 22, 2013 at 3:32 PM, Andrew Grieve agri...@chromium.org wrote:
In google doc form:
https://docs.google.com/document/d/1s617PCwJm_lOjybHAnkgm5WdoDdU113fkGBCrlPghxE/edit
On Tue, Jan 22, 2013 at 3:29
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
Am I correct in assuming US pacific time zone?
Sent from my iPad
On Jan 15, 2013, at 4:36 AM, Brian LeRoux b...@brian.io wrote:
Works for me, however, to accommodate EU community we must to consider
times unholy. This is Apache Way from what I understand.
I created a form to help us pick a
Thanks for coordinating schedules Brain. Im quite glad to be on EST :)
We should also establish a medium: Google hangouts were not well received
by everyone last year, (not everyone had a G+ account), but I cannot think
of anything that is nearly as convenient. Suggestions?
-Michal
On Tue,
Becky: yes PST!
Michal: I can setup a bridge using either Gotomeeting (Citrix, Java)
or Connect (Adobe, Flash). Still a ways out from that WebRTC ideal.
On Tue, Jan 15, 2013 at 6:22 AM, Michal Mocny mmo...@chromium.org wrote:
Thanks for coordinating schedules Brain. Im quite glad to be on EST
Yay for grannies using G+! (mine does, too, which is great, and far less
annoying than her FB game invites!)
On Tue, Jan 15, 2013 at 1:18 PM, Filip Maj f...@adobe.com wrote:
I was the one who didn't want to sign up for G+ :)
Now it's a moot point as my gramma uses it and so, by proxy, I am
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
Ok. Lets go at this from a workflow perspective. One thing I'd like to
note is the two classifications of branch.
There are canonical branches:
- Dev (or Master)
- Unstable (or Next)
- Stable
And then there are feature branches.
Feature branches merge into Canonical branches as appropriate.
But do Canonical branches merge into each other? I'm thinking no.
My understanding:
- work goes into feature branches
- when contributor(s) deem feature is ready, merge into Unstable, which
then gets vetted (test!)
- at some point unstable merges into Next
- when tagging, we merge Next into
On Mon, Jan 14, 2013 at 4:54 PM, Filip Maj f...@adobe.com wrote:
But do Canonical branches merge into each other? I'm thinking no.
My understanding:
- work goes into feature branches
- when contributor(s) deem feature is ready, merge into Unstable, which
then gets vetted (test!)
- at
So, what if Canonical branches only received merges from Feature branches...?
On Mon, Jan 14, 2013 at 2:02 PM, Andrew Grieve agri...@chromium.org wrote:
On Mon, Jan 14, 2013 at 4:54 PM, Filip Maj f...@adobe.com wrote:
But do Canonical branches merge into each other? I'm thinking no.
My
Andrew beat me to it. I don't see how feature branches can be practical. We
would have to keep track of all the feature branches on the server, and
their current merged state.
I think it makes sense for all new commits to go into unstable, whether
they be urgent bug fixes or new features or
My ideal here is to get to a point where there is something, whatever
it is, that we want to denote as a release. That something should not
require a whole bunch of coordination. There should be a working
branch, whatever we call it, ready for a tag and nothing else on any
arbitrary date to be
My ideal here is to get to a point where there is something, whatever
it is, that we want to denote as a release. That something should not
require a whole bunch of coordination. There should be a working
branch, whatever we call it, ready for a tag and nothing else on any
arbitrary date to
Aside from the extra overhead and coordination, which I think are a major
problem, this is a recipe for disaster with merge commits. This doesn't
require manual conflict resolution to be a problem. Just that, if feature
branches A and B are merged into dev/unstable and a merge commit is
created,
Hey shawn, feel free to kick up a new thread about Windows Phone dev.
We'd love your help. You can read how we'd like you to work w/ us
here:
http://wiki.apache.org/cordova/ContributorWorkflow
On Mon, Jan 14, 2013 at 2:33 PM, Shawn Wildermuth
shawn.li...@agilitrain.com wrote:
Anyone actively
Oh, yes, that is true. I was assuming (naively) that this wouldn't be
a likely case if we were diligent about rebasing before commits
landing.
So, the real trick here is, a workflow of:
feature -- dev -- unstable -- stable
When, and more importantly who, does the Canonical brach to Canonical
Shawn, be aware that there are separate git repos for Windows desktop 8,
WP7, and WP8.
On 1/14/2013 5:33 PM, Shawn Wildermuth wrote:
- Upgrade it to support WP8
Sorry if this got asked before, but does a feature branch get deleted
after it is merged? Just wondering about branch clutter over a long
period, or if this is just the same as a topic branch using today's
committer workflow.
On 1/14/2013 5:34 PM, Brian LeRoux wrote:
You work on a Feature
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
On Mon, Jan 14, 2013 at 9:40 PM, Marcel
I don't think there's any advantage to creating them ahead of time, so we
might as well not bother.
On Fri, Jan 11, 2013 at 10:32 AM, Braden Shepherdson bra...@chromium.orgwrote:
Maybe I'm being coloured by the Chrome channels, but it seems to me that we
would be doing our development of the
I think we all agree on the general flow of feature branch - staging -
merge into master + tag.
Ripple uses next as the label for the branch with all stuff going into
the next release. I like this approach.
On 1/11/13 7:48 AM, Andrew Grieve agri...@chromium.org wrote:
I don't think there's any
Poking this thread. So is there consensus on how to do this? If so, can
this be summarized and written up, perhaps on the ContributorWorkflow /
CommiterWorkflow wiki pages?
And when would we want to start operating with this, 2.4/now or later?
-- Marcel Kinard
Thank you. I lean to agreement w/ Andrew that more meaningful pull
reqs are better and having named branches for what they do makes
sense. Also agree that tags are for points in time---but I take no
exception to a branch for those as well for dev purposes.
Let me try to capture the conversation
On Wed, Jan 2, 2013 at 11:05 PM, Michal Mocny mmo...@chromium.org wrote:
On Wed, Jan 2, 2013 at 7:27 PM, Andrew Grieve agri...@chromium.org
wrote:
From my understanding of git, there's nothing special about the master
branch, except that it's what gets checked out when someone doesn't
On Thu, Jan 3, 2013 at 9:43 AM, Andrew Grieve agri...@chromium.org wrote:
On Wed, Jan 2, 2013 at 11:05 PM, Michal Mocny mmo...@chromium.org wrote:
On Wed, Jan 2, 2013 at 7:27 PM, Andrew Grieve agri...@chromium.org
wrote:
From my understanding of git, there's nothing special about the
OK, Let's rethink this:
After talking with Brian on the 21st, I think we agree on this:
* Master remains stable and sits at the most recent released code
(i.e. 2.3.0 once we get 2.3.0 done) (Stable Channel)
* Dev happens on branches for the releases (i.e. 2.4.0) (Dev Channel)
* In the case of
Am I correct when I say that, with this approach, master becomes a series
of merge commits coming from dev, then ?
A couple questions to follow up:
- features get forked from stable - forked from master, yes?
- features, when ready, tested against dev branch - what does this mean?
Does this
On Wed, Jan 2, 2013 at 11:32 AM, Filip Maj f...@adobe.com wrote:
Am I correct when I say that, with this approach, master becomes a series
of merge commits coming from dev, then ?
That's correct!
A couple questions to follow up:
- features get forked from stable - forked from master, yes?
This is what we have done in ripple (and webworks)
master - always stable current shipping code
next - always 'stable' next release. Expectation that code has been tested
/ run before merged into this branch.
feature branches - branched off of next and merged into next when stable /
done. Not
I don't have much weight here, but personally I feel that this seems
backwards.
With this proposal (if I understand it), when you do a fresh checkout of
the codebase, instead of sitting on the bleeding edge, you would be sitting
at a stable release which is conceptually read-only for most
Also: while I personally prefer master to be the dev channel, I will say
that I do like Gord's suggestion of how its done in ripple in that the name
of the dev branch is 'next' and not '2.3.0' so that your dev setup doesn't
need to change every month.
Gord: how do you deal with bugfixes/point
Also a problem we have encountered with using a 'next' branch for active
development is from third party commits.
Every single 3rd party pull request is going to come into master.
You can ether:
1. tell them to redo it on next
2. rebase it into next for them and let them know for next time.
The
On Wed, Jan 2, 2013 at 7:27 PM, Andrew Grieve agri...@chromium.org wrote:
From my understanding of git, there's nothing special about the master
branch, except that it's what gets checked out when someone doesn't
explicitly say which branch they want.
Joe pointed out that sometimes random
I definitely think we'd get more done if we didn't have such a long
code-freeze. I'm not sure this is the same as what you were suggesting, but
have a script/tool to branch all of the platforms into an rc branch. Then,
each platform can fix themselves up a bit and tag their RC. Meanwhile, dev
can
So there is something to be said about having devs shift focus from dev to
testing during an RC. However, as the team grows, not all of us are really
being responsible for cutting releases. Maybe that means we need to train
the entire team to change current behavior, but that doesn't feel
(I like the idea of 3 long lived branches, but I am biased!)
Joe: It sounded like you were proposing dev in remote branches and master
is used only for merging, but then say that dev in remote branches is a
invisible and a pain -- now I'm not sure if you are proposing for/against.
Personally I
So, it takes us roughly a week to socialize a release. We tag the JS.
We go back and forth on the list a little. We retag the JS. =)
Personally, I think the addition of RC to the process made this
easier. But perhaps its time to add a new channel wherein we are more
strict about the tagging of
73 matches
Mail list logo
