David Blevins wrote:
On Jun 25, 2006, at 8:49 PM, Alan D. Cabrera wrote:
Greg Wilkins wrote:
I think the wiki should clarify the patch process for release branches.
Agreed. I have added slight caveats for
New Features:
develop in trunk
patch to current x.y branch (if to be captured in
Thanks David.
David Blevins wrote:
On Jun 25, 2006, at 8:49 PM, Alan D. Cabrera wrote:
Greg Wilkins wrote:
I think the wiki should clarify the patch process for release branches.
Agreed. I have added slight caveats for
New Features:
develop in trunk
patch to current x.y branch (if to
+1
while I have some quibbles with the process it is much better to
have an agred well defined process than it is to have a constant debate
about a perfect one.
I think the wiki should clarify the patch process for release branches.
Personally I think that there are two processes:
New
Greg Wilkins wrote:
I think the wiki should clarify the patch process for release branches.
Agreed. I have added slight caveats for
New Features:
develop in trunk
patch to current x.y branch (if to be captured in next x.y.z release)
Fixes
develop in x.y branch (if to be captured in
I don't quite understand what you are asking. Can you rephrase?
Regards,
Alan
Jason Dillon wrote:
Does this mean that the bulk of changes will be done on M.m branches
and only release + minor changes done on M.m.r branches?
--jason
On Jun 21, 2006, at 6:52 PM, David Blevins wrote:
We
On Jun 21, 2006, at 10:53 PM, Alan D. Cabrera wrote:
David Blevins wrote:
The only thing done in a branches/x.y.z made from branches/x.y is
the release process itself.
I don't quite understand what this means. Sorry.
Referring to things like switching the version numbers, etc. The
Okay, then +1
--jason
On Jun 21, 2006, at 10:19 PM, David Blevins wrote:
The only thing done in a branches/x.y.z made from branches/x.y is
the release process itself. When we agree we look good enough to
cut and run, we freeze, make the branch and put together a release
candidate. At
+1, but if we cut a release from the frozen branch, we need to note
the SVN version number or something so when we move it to tags we're
absolutely sure we didn't catch an extra commit in the tag. I'm also
fine with copying to tags, making the candidate from tags, and then
recreating the tag if
+1 (and we need to make sure this is added to the wiki so we can
remember it the next time a release is spun :-))
David Blevins wrote:
We had this whole conversation last week, lots of good discussion was
had. I'd prefer not to have to have it again. Here is my exact
understanding of our
I think moving from branches to tags and back again is too disruptive. The reason it sits in its
own area in branches is so that it can be finalized and then copied once its done. If we have to
then we have to but this should be the rare exception that something is caught after the final vote
Thanks David, I tried to recap in the other thread and didn't receive any additional responses so
now that we have a branches/1.1.0 branches/1.1 and a branches/1.1.1 I don't think we quite nailed
it. Your summary is great and I concur.
Here is my + 1 and I'm happy to get the Wiki updated.
David Blevins wrote:
On Jun 21, 2006, at 10:53 PM, Alan D. Cabrera wrote:
David Blevins wrote:
The only thing done in a branches/x.y.z made from branches/x.y is
the release process itself.
I don't quite understand what this means. Sorry.
Referring to things like switching the version
+1 to David's recap and to Matts plans below.
John
Matt Hogstrom wrote:
Thanks David, I tried to recap in the other thread and didn't receive
any additional responses so now that we have a branches/1.1.0
branches/1.1 and a branches/1.1.1 I don't think we quite nailed it.
Your summary is
+1
Gianny
David Blevins wrote:
We had this whole conversation last week, lots of good discussion was
had. I'd prefer not to have to have it again. Here is my exact
understanding of our consensus and would like to put it to a vote to
avoid reinterpretation of that consensus in the future.
+1 to david and alan's annotations.
Lets get it in the wiki!
thanks
david jencks
On Jun 22, 2006, at 4:06 AM, Alan D. Cabrera wrote:
+1
I think that we should mention that patches that go into
x.y.z also go into x.y and trunk
x.y also go into trunk
Last time we neglected to apply patches
On 6/22/06, Matt Hogstrom [EMAIL PROTECTED] wrote:
Thanks David, I tried to recap in the other thread and didn't receive any
additional responses so
now that we have a branches/1.1.0 branches/1.1 and a branches/1.1.1 I don't
think we quite nailed
it. Your summary is great and I concur.
Here
On Jun 22, 2006, at 2:01 AM, Rick McGuire wrote:
+1 (and we need to make sure this is added to the wiki so we can
remember it the next time a release is spun :-))
Definitely, was waiting to see some +1s before doing that part.
Here it is:
Then I think we're open for G-Business.
I love it... G-Business :-)
--jason
On Jun 22, 2006, at 3:17 AM, Matt Hogstrom wrote:
The remaining question is what to do with the branches that are out
there. I think we should whack what's out there (does not appear
that there has been any activity) branches/1.1 and branches/1.1.1.
When the vote is complete later today
We had this whole conversation last week, lots of good discussion was
had. I'd prefer not to have to have it again. Here is my exact
understanding of our consensus and would like to put it to a vote to
avoid reinterpretation of that consensus in the future.
1. branches/x.y would be the
+1
I think that we should mention that patches that go into
x.y.z also go into x.y and trunk
x.y also go into trunk
Last time we neglected to apply patches evenly across the board when
fixes were checked into one branch. This is one reason why the versions
drifted so wildly apart.
+1
-dain
On Jun 21, 2006, at 7:06 PM, Alan D. Cabrera wrote:
+1
I think that we should mention that patches that go into
x.y.z also go into x.y and trunk
x.y also go into trunk
Last time we neglected to apply patches evenly across the board
when fixes were checked into one branch. This
+1
On 6/21/06, Alan D. Cabrera [EMAIL PROTECTED] wrote:
+1
I think that we should mention that patches that go into
x.y.z also go into x.y and trunk
x.y also go into trunk
Last time we neglected to apply patches evenly across the board when
fixes were checked into one branch. This is one
David,
Thanks for that excellent recap.
+1 from me.
+1 to Alan's comment that all patches to branches should also be
applied to the trunk. Any future x.(y+1) branch should come from the
trunk and not from the recently frozen x.y.z branch.
Cheers
Prasad
On 6/21/06, Hiram Chirino [EMAIL
Does this mean that the bulk of changes will be done on M.m branches
and only release + minor changes done on M.m.r branches?
--jason
On Jun 21, 2006, at 6:52 PM, David Blevins wrote:
We had this whole conversation last week, lots of good discussion was
had. I'd prefer not to have to have
The only thing done in a branches/x.y.z made from branches/x.y is the
release process itself. When we agree we look good enough to cut and
run, we freeze, make the branch and put together a release
candidate. At the point of the freeze the release manager owns the
branches/x.y.z till the
David Blevins wrote:
The only thing done in a branches/x.y.z made from branches/x.y is the
release process itself.
I don't quite understand what this means. Sorry.
When we agree we look good enough to cut and run, we freeze, make the
branch and put together a release candidate. At the
27 matches
Mail list logo
