Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.

[Matt Hogstrom <ma...@hogstrom.org>]

After the branches/1.1 was moved to tags there was some question as to what happened to the 1.1 
branch.  At that time some kind soul created a new branches/1.1.1.  No activity has occurred in that 
branch and given that we'll need to define the release goals of 1.1.1 soon I'd like to propose the 
following.

After 1.1 is released:

* Delete branches/1.1.1
* Move branches/1.1.0 to tags/1.1.0
* Copy tags/1.1.0 to branches/1.1.1
* Update branches 1.1.1 to be 1.1.1-SNAPSHOT
* Start working on 1.1.1

When 1.1.1 enters time for release

* Move branches/1.1.1 to branches/1.1.1.0
* Change version from 1.1.1-SNAPSHOT to 1.1.1
* Create release candidate rc1
* put out for a vote
* get a successful vote with no respins :)
* move from branches/1.1.1.0 to tags/1.1.1.0

Based on all the confusion in the past I think this procedure makes it clear what phase were in for 
the release as well as avoids tagging and branching repeatedly.

I'm looking for lazy consensus and not a formal vote.

Matt

Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.

[David Blevins <da...@visi.com>]

On Jun 21, 2006, at 5:18 PM, Jason Dillon wrote:

>> Hi Jason,
>>
>> I agree that we should avoid branching.  But I do agree with the  
>> 1.1.1
>> branch.  It's a dead-end branch in that it's only used to prepare he
>> release.  Applying last minute fixes and changing version numbers.
>> Since it's a dead-end branch, once the release if approved
>> moving/deleting it makes sense.
>
> I would make those changes on the 1.1 branch (or trunk if we were  
> using that codebase), then release and let Maven make the tag and  
> then update the versions to the next SNAP.
>
> When moving to m2 we really need to follow the m2 release system,  
> else the number of changes to poms is going to get out of control  
> and will be very error prone.
>

s/is going to get out of control/has gotten out of control/

It's already a problem, hence the strong need for a "frozen" branch  
in which to switch the version numbers over.

For the weekly builds with the svn revision number instead of  
snaphsot, I use these commands to switch the version.

	perl -i.orig -pe 's,(-SNAPSHOT)?$,-$ENV{SVN_VERSION}, if /^ 
(geronimo.packaging.)?geronimo_?(.*?plugin_)?[Vv]ersion=/' etc/ 
project.properties  plugins/*/*.properties

	perl -i.orig -pe '
s,(</currentVersion>),-$ENV{SVN_VERSION}$1, unless /SNAPSHOT/;
s,-SNAPSHOT(</currentVersion>),-$ENV{SVN_VERSION}$1,;
s,-SNAPSHOT(</(dep:)?version>),-$ENV{SVN_VERSION}$1, if $p2 =~ /< 
(dep:)?groupId>geronimo/;
$p2=$p1; $p1=$_;
' plugins/*/project.xml plugins/geronimo-packaging-plugin/src/test- 
resources/*.xml

	perl -i.orig -pe 's,(-SNAPSHOT)?$,-$ENV{SVN_VERSION}, if / 
^geronimo...=/' etc/explicit_versions.properties

Maven can't handle that.

-David

Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.

[Jason Dillon <ja...@planet57.com>]

> I think your right if nothing needs to change.  IIUC there is a  
> general preference for tags being pristine with no modifications.

Generally I agree with this.


> So, if a release can go from being worked to a good release then  
> the Maven system is great.  I think the reality is that there will  
> generally be the time required to wait for a release to bake.  If  
> changes are needed then they either need to be applied to the  
> tagged version or copied and re-tagged (which IMHO is really  
> undesireable).

What kind of release backing are we talking about?


> I think the idea of no changes to tags makes sense.  If Maven could  
> handle the process and take into account the timing and possible re- 
> work that would be awesome.  Right now the 1.1.0 release has been  
> there for the better part of two weeks.  I don't think we want to  
> stall development like this in the future.

Agreed.  Maven should be able to help... m2 that is, not sure about  
m1.  I'm going to experiment with a GShell release, but from what I  
understand, the release plugin should automate most of the details.

We'll see.

--jason

Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.

[Matt Hogstrom <ma...@hogstrom.org>]

I think your right if nothing needs to change.  IIUC there is a general preference for tags being 
pristine with no modifications.  So, if a release can go from being worked to a good release then 
the Maven system is great.  I think the reality is that there will generally be the time required to 
wait for a release to bake.  If changes are needed then they either need to be applied to the tagged 
version or copied and re-tagged (which IMHO is really undesireable).

I think the idea of no changes to tags makes sense.  If Maven could handle the process and take into 
account the timing and possible re-work that would be awesome.  Right now the 1.1.0 release has been 
there for the better part of two weeks.  I don't think we want to stall development like this in the 
future.

If there is a way to address this with m2  that would be great.

Jason Dillon wrote:
>> Hi Jason,
>>
>> I agree that we should avoid branching.  But I do agree with the 1.1.1
>> branch.  It's a dead-end branch in that it's only used to prepare he
>> release.  Applying last minute fixes and changing version numbers.
>> Since it's a dead-end branch, once the release if approved
>> moving/deleting it makes sense.
> 
> I would make those changes on the 1.1 branch (or trunk if we were using 
> that codebase), then release and let Maven make the tag and then update 
> the versions to the next SNAP.
> 
> When moving to m2 we really need to follow the m2 release system, else 
> the number of changes to poms is going to get out of control and will be 
> very error prone.
> 
> --jason
> 
> 
> 
> 
> 

Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.

[Hiram Chirino <hi...@hiramchirino.com>]

On 6/22/06, Aaron Mulder <am...@alumni.princeton.edu> wrote:
> +1 To Jason's comments with Hiram's comments...
>
> I think we should do all development of 1.1.x in branches/1.1 (with
> version 1.1.N-SNAPSHOT).  But at the time we code freeze for a
> release, I think we should svn copy branches/1.1 to branches/1.1.N and
> finalize the version numbers there (to version 1.1.N) and make any
> last-minute tweaks there and update branches/1.1 to version number
> 1.1.(N+1)-SNAPSHOT.  When we have a candidate for the release, then we
> can svn copy branches/1.1.N to tags/1.1.N and build the release from
> the tag.

BTW: I don't think there is any harm in doing the release from the
branch if the branch is copied to the tag since the source code should
be identical between them.  I think we should perhaps avoid creating
the the tag until we KNOW that the binary is approved.

>
> Thanks,
>    Aaron
>
> On 6/21/06, Hiram Chirino <hi...@hiramchirino.com> wrote:
> > Hi Jason,
> >
> > The problem is that it can take weeks to do a geronimo release since
> > stuff like CTS testing is involved.  So the release work (putting the
> > finishing touches) needs to be done in a branch so that work can
> > continue on the next release.
> >
> > Perhaps m2 has a way of dealing with those issues along with
> > re-cutting releases and such.  But since I have not done a m2 based
> > release yet, I'm not sure what's involved.  Could you clarify it a bit
> > for me?
> >
> > On 6/21/06, Jason Dillon <ja...@planet57.com> wrote:
> > > > Hi Jason,
> > > >
> > > > I agree that we should avoid branching.  But I do agree with the 1.1.1
> > > > branch.  It's a dead-end branch in that it's only used to prepare he
> > > > release.  Applying last minute fixes and changing version numbers.
> > > > Since it's a dead-end branch, once the release if approved
> > > > moving/deleting it makes sense.
> > >
> > > I would make those changes on the 1.1 branch (or trunk if we were
> > > using that codebase), then release and let Maven make the tag and
> > > then update the versions to the next SNAP.
> > >
> > > When moving to m2 we really need to follow the m2 release system,
> > > else the number of changes to poms is going to get out of control and
> > > will be very error prone.
> > >
> > > --jason
> > >
> > >
> > >
> >
> >
> > --
> > Regards,
> > Hiram
> >
> > Blog: http://hiramchirino.com
> >
>


-- 
Regards,
Hiram

Blog: http://hiramchirino.com

Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.

[Aaron Mulder <am...@alumni.princeton.edu>]

+1 To Jason's comments with Hiram's comments...

I think we should do all development of 1.1.x in branches/1.1 (with
version 1.1.N-SNAPSHOT).  But at the time we code freeze for a
release, I think we should svn copy branches/1.1 to branches/1.1.N and
finalize the version numbers there (to version 1.1.N) and make any
last-minute tweaks there and update branches/1.1 to version number
1.1.(N+1)-SNAPSHOT.  When we have a candidate for the release, then we
can svn copy branches/1.1.N to tags/1.1.N and build the release from
the tag.

Thanks,
   Aaron

On 6/21/06, Hiram Chirino <hi...@hiramchirino.com> wrote:
> Hi Jason,
>
> The problem is that it can take weeks to do a geronimo release since
> stuff like CTS testing is involved.  So the release work (putting the
> finishing touches) needs to be done in a branch so that work can
> continue on the next release.
>
> Perhaps m2 has a way of dealing with those issues along with
> re-cutting releases and such.  But since I have not done a m2 based
> release yet, I'm not sure what's involved.  Could you clarify it a bit
> for me?
>
> On 6/21/06, Jason Dillon <ja...@planet57.com> wrote:
> > > Hi Jason,
> > >
> > > I agree that we should avoid branching.  But I do agree with the 1.1.1
> > > branch.  It's a dead-end branch in that it's only used to prepare he
> > > release.  Applying last minute fixes and changing version numbers.
> > > Since it's a dead-end branch, once the release if approved
> > > moving/deleting it makes sense.
> >
> > I would make those changes on the 1.1 branch (or trunk if we were
> > using that codebase), then release and let Maven make the tag and
> > then update the versions to the next SNAP.
> >
> > When moving to m2 we really need to follow the m2 release system,
> > else the number of changes to poms is going to get out of control and
> > will be very error prone.
> >
> > --jason
> >
> >
> >
>
>
> --
> Regards,
> Hiram
>
> Blog: http://hiramchirino.com
>

Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.

[Jason Dillon <ja...@planet57.com>]

> Hi Jason,

Hiya :-)


> The problem is that it can take weeks to do a geronimo release since
> stuff like CTS testing is involved.  So the release work (putting the
> finishing touches) needs to be done in a branch so that work can
> continue on the next release.

I would hope that most if not all of the issues should be resolved  
wrt/CTS/TCK before making a release...

But, if this branch exists only for the reason of facilitating this  
time consuming process, and no merging is to be done, then I think it  
will work.

I think that all development should be done on the 1.1 (or trunk) or  
M.m branch, and only release work on any M.m.r branches, and at the  
end of the release that branch is moved to a tag and never modified  
again.  Future modifications will copy from the tag to a branch, and  
the cycle continues.


> Perhaps m2 has a way of dealing with those issues along with
> re-cutting releases and such.  But since I have not done a m2 based
> release yet, I'm not sure what's involved.  Could you clarify it a bit
> for me?

I'm actually still sorting that out.  I'm going to use m2 for GShell  
releases and I want to get a 0.0.1 out soonish to test it all out.   
I've got a little experence with it, and it does make it much easier,  
since for m2 every pom.xml needs to change when a version is changed :-(

--jason

Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.

[Guillaume Nodet <gn...@gmail.com>]

According to the maven guys, the release process is:
  * deploy snapshot
  * vote on snapshot
  * build and deploy a release

Currently the m2 release process (if you use the release plugin is):
  * change all versions in poms and commit
  * create a tag
  * release and deploy from tag
  * revert to snapshots and commit
AFAIK, this can be done from trunk or branch.

The only problem i see is that you have currently no way to:
  * deploy to a private repo without changing the pom
  * promote a build to a release, so once a build has been voted,
     the release must be rebuild and redeployed (the binaries are different)

Cheers,
Guillaume Nodet



On 6/22/06, Hiram Chirino <hi...@hiramchirino.com> wrote:
>
> Hi Jason,
>
> The problem is that it can take weeks to do a geronimo release since
> stuff like CTS testing is involved.  So the release work (putting the
> finishing touches) needs to be done in a branch so that work can
> continue on the next release.
>
> Perhaps m2 has a way of dealing with those issues along with
> re-cutting releases and such.  But since I have not done a m2 based
> release yet, I'm not sure what's involved.  Could you clarify it a bit
> for me?
>
> On 6/21/06, Jason Dillon <ja...@planet57.com> wrote:
> > > Hi Jason,
> > >
> > > I agree that we should avoid branching.  But I do agree with the 1.1.1
> > > branch.  It's a dead-end branch in that it's only used to prepare he
> > > release.  Applying last minute fixes and changing version numbers.
> > > Since it's a dead-end branch, once the release if approved
> > > moving/deleting it makes sense.
> >
> > I would make those changes on the 1.1 branch (or trunk if we were
> > using that codebase), then release and let Maven make the tag and
> > then update the versions to the next SNAP.
> >
> > When moving to m2 we really need to follow the m2 release system,
> > else the number of changes to poms is going to get out of control and
> > will be very error prone.
> >
> > --jason
> >
> >
> >
>
>
> --
> Regards,
> Hiram
>
> Blog: http://hiramchirino.com
>

Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.

[Hiram Chirino <hi...@hiramchirino.com>]

Hi Jason,

The problem is that it can take weeks to do a geronimo release since
stuff like CTS testing is involved.  So the release work (putting the
finishing touches) needs to be done in a branch so that work can
continue on the next release.

Perhaps m2 has a way of dealing with those issues along with
re-cutting releases and such.  But since I have not done a m2 based
release yet, I'm not sure what's involved.  Could you clarify it a bit
for me?

On 6/21/06, Jason Dillon <ja...@planet57.com> wrote:
> > Hi Jason,
> >
> > I agree that we should avoid branching.  But I do agree with the 1.1.1
> > branch.  It's a dead-end branch in that it's only used to prepare he
> > release.  Applying last minute fixes and changing version numbers.
> > Since it's a dead-end branch, once the release if approved
> > moving/deleting it makes sense.
>
> I would make those changes on the 1.1 branch (or trunk if we were
> using that codebase), then release and let Maven make the tag and
> then update the versions to the next SNAP.
>
> When moving to m2 we really need to follow the m2 release system,
> else the number of changes to poms is going to get out of control and
> will be very error prone.
>
> --jason
>
>
>


-- 
Regards,
Hiram

Blog: http://hiramchirino.com

Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.

[Jason Dillon <ja...@planet57.com>]

> Hi Jason,
>
> I agree that we should avoid branching.  But I do agree with the 1.1.1
> branch.  It's a dead-end branch in that it's only used to prepare he
> release.  Applying last minute fixes and changing version numbers.
> Since it's a dead-end branch, once the release if approved
> moving/deleting it makes sense.

I would make those changes on the 1.1 branch (or trunk if we were  
using that codebase), then release and let Maven make the tag and  
then update the versions to the next SNAP.

When moving to m2 we really need to follow the m2 release system,  
else the number of changes to poms is going to get out of control and  
will be very error prone.

--jason

Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.

[Hiram Chirino <hi...@hiramchirino.com>]

On 6/21/06, Jason Dillon <ja...@planet57.com> wrote:
> Why would a "branch" get moved to a "tag"?  Why do we need branches
> for revisions?  Why are we deleting branches?
>
> IMO, we should have a branch for each Major.Minor, where all of the
> Major.Minor.Revision work happens.  So branches/1.1 would hold the
> active work for 1.1.x.  When it is time to make a release, then svn
> cp from branches/1.1 to tags/1.1.1, and then keep working on 1.1.2 on
> branches/1.1
>
> IMO, branches should never become tags.  Tags only get copied to new
> branches when we need to apply critical fix to a specific release,
> otherwise we should just roll up the change into the next release of
> the series.
>
> I recommend minimizing branching where possible, so I don't think
> that branches for 1.1.1 or 1.1.1.0 are a good idea.  SVN is not that
> good at merging, and making it simple (like Perforce), so lets try
> not to set ourselves up for icky merges by making branches for each
> release.

Hi Jason,

I agree that we should avoid branching.  But I do agree with the 1.1.1
branch.  It's a dead-end branch in that it's only used to prepare he
release.  Applying last minute fixes and changing version numbers.
Since it's a dead-end branch, once the release if approved
moving/deleting it makes sense.

>
> --jason
>
>
> On Jun 21, 2006, at 4:14 PM, Matt Hogstrom wrote:
>
> > After the branches/1.1 was moved to tags there was some question as
> > to what happened to the 1.1 branch.  At that time some kind soul
> > created a new branches/1.1.1.  No activity has occurred in that
> > branch and given that we'll need to define the release goals of
> > 1.1.1 soon I'd like to propose the following.
> >
> > After 1.1 is released:
> >
> > * Delete branches/1.1.1
> > * Move branches/1.1.0 to tags/1.1.0
> > * Copy tags/1.1.0 to branches/1.1.1
> > * Update branches 1.1.1 to be 1.1.1-SNAPSHOT
> > * Start working on 1.1.1
> >
> > When 1.1.1 enters time for release
> >
> > * Move branches/1.1.1 to branches/1.1.1.0
> > * Change version from 1.1.1-SNAPSHOT to 1.1.1
> > * Create release candidate rc1
> > * put out for a vote
> > * get a successful vote with no respins :)
> > * move from branches/1.1.1.0 to tags/1.1.1.0
> >
> > Based on all the confusion in the past I think this procedure makes
> > it clear what phase were in for the release as well as avoids
> > tagging and branching repeatedly.
> >
> > I'm looking for lazy consensus and not a formal vote.
> >
> > Matt
>
>


-- 
Regards,
Hiram

Blog: http://hiramchirino.com

Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.

[Jason Dillon <ja...@planet57.com>]

Why would a "branch" get moved to a "tag"?  Why do we need branches  
for revisions?  Why are we deleting branches?

IMO, we should have a branch for each Major.Minor, where all of the  
Major.Minor.Revision work happens.  So branches/1.1 would hold the  
active work for 1.1.x.  When it is time to make a release, then svn  
cp from branches/1.1 to tags/1.1.1, and then keep working on 1.1.2 on  
branches/1.1

IMO, branches should never become tags.  Tags only get copied to new  
branches when we need to apply critical fix to a specific release,  
otherwise we should just roll up the change into the next release of  
the series.

I recommend minimizing branching where possible, so I don't think  
that branches for 1.1.1 or 1.1.1.0 are a good idea.  SVN is not that  
good at merging, and making it simple (like Perforce), so lets try  
not to set ourselves up for icky merges by making branches for each  
release.

--jason


On Jun 21, 2006, at 4:14 PM, Matt Hogstrom wrote:

> After the branches/1.1 was moved to tags there was some question as  
> to what happened to the 1.1 branch.  At that time some kind soul  
> created a new branches/1.1.1.  No activity has occurred in that  
> branch and given that we'll need to define the release goals of  
> 1.1.1 soon I'd like to propose the following.
>
> After 1.1 is released:
>
> * Delete branches/1.1.1
> * Move branches/1.1.0 to tags/1.1.0
> * Copy tags/1.1.0 to branches/1.1.1
> * Update branches 1.1.1 to be 1.1.1-SNAPSHOT
> * Start working on 1.1.1
>
> When 1.1.1 enters time for release
>
> * Move branches/1.1.1 to branches/1.1.1.0
> * Change version from 1.1.1-SNAPSHOT to 1.1.1
> * Create release candidate rc1
> * put out for a vote
> * get a successful vote with no respins :)
> * move from branches/1.1.1.0 to tags/1.1.1.0
>
> Based on all the confusion in the past I think this procedure makes  
> it clear what phase were in for the release as well as avoids  
> tagging and branching repeatedly.
>
> I'm looking for lazy consensus and not a formal vote.
>
> Matt

Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)

[Dain Sundstrom <da...@iq80.com>]

+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 is one reason why  
> the versions drifted so wildly apart.
>
> Regards,
> Alan
>
> 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.   branches/x.y would be the branch for all x.y.z releases
>>
>> 2.   when a release is frozen, we spin off a branch with that *exact*
>>      name, as in branches/x.y.z, where z starts at zero and  
>> increments
>>      by one.
>>
>> 3.   at that time branches/x.y is immediately updated to version
>>      x.y.(z+1)-SNAPSHOT
>>
>> 3.   We cut releases from the frozen branch
>>
>> 4.   When a release passes final tck testing and final vote, the
>>      frozen branch is moved to tags
>>
>> We create a branch at freeze time for the following reasons:
>>
>> 1.  it takes *at least* one week from freeze to ship due to voting,
>>     tck testing and potential repeats of that process (re-cut,
>>     re-certify, re-vote).  There is no reason why work on x.y.z+1
>>     needs to be delayed -- only 52 weeks a year.
>>
>> 2.  stronger guarantee no one is updating the branch once frozen
>>
>> 3.  less likely that people and ci systems (continuum) will checkout
>>     and build pre-release versions of x.y.z (not x.y.z-SNAPSHOT)  
>> which
>>     would need to be removed manually and may accidentally be
>>     distributed.
>>
>> 4.  it is currently very difficult to roll version numbers forward,
>>     entries here and there are often missed.  Far better to have
>>     branches/x.y have a few straggling old x.y.z-SNAPSHOT versions
>>     than a few overlooked x.y.z final numbers that needed to go back
>>     to SNAPSHOT -- they never leave SNAPSHOT and need to be reverted
>>     back later if that process happens in the frozen branch.
>>
>>
>> Here is my +1
>>
>>
>> -- David
>>
>>
>>
>> On Jun 21, 2006, at 4:14 PM, Matt Hogstrom wrote:
>>
>>> After the branches/1.1 was moved to tags there was some question  
>>> as to what happened to the 1.1 branch.  At that time some kind  
>>> soul created a new branches/1.1.1.  No activity has occurred in  
>>> that branch and given that we'll need to define the release goals  
>>> of 1.1.1 soon I'd like to propose the following.
>>>
>>> After 1.1 is released:
>>>
>>> * Delete branches/1.1.1
>>> * Move branches/1.1.0 to tags/1.1.0
>>> * Copy tags/1.1.0 to branches/1.1.1
>>> * Update branches 1.1.1 to be 1.1.1-SNAPSHOT
>>> * Start working on 1.1.1
>>>
>>> When 1.1.1 enters time for release
>>>
>>> * Move branches/1.1.1 to branches/1.1.1.0
>>> * Change version from 1.1.1-SNAPSHOT to 1.1.1
>>> * Create release candidate rc1
>>> * put out for a vote
>>> * get a successful vote with no respins :)
>>> * move from branches/1.1.1.0 to tags/1.1.1.0
>>>
>>> Based on all the confusion in the past I think this procedure  
>>> makes it clear what phase were in for the release as well as  
>>> avoids tagging and branching repeatedly.
>>>
>>> I'm looking for lazy consensus and not a formal vote.
>>>
>>> Matt
>>>
>>

Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)

[Prasad Kashyap <go...@gmail.com>]

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 <hi...@hiramchirino.com> wrote:
> +1
>
> On 6/21/06, Alan D. Cabrera <li...@toolazydogs.com> 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 reason why the versions
> > drifted so wildly apart.
> >
> > Regards,
> > Alan
> >
> > 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.   branches/x.y would be the branch for all x.y.z releases
> > >
> > > 2.   when a release is frozen, we spin off a branch with that *exact*
> > >      name, as in branches/x.y.z, where z starts at zero and increments
> > >      by one.
> > >
> > > 3.   at that time branches/x.y is immediately updated to version
> > >      x.y.(z+1)-SNAPSHOT
> > >
> > > 3.   We cut releases from the frozen branch
> > >
> > > 4.   When a release passes final tck testing and final vote, the
> > >      frozen branch is moved to tags
> > >
> > > We create a branch at freeze time for the following reasons:
> > >
> > > 1.  it takes *at least* one week from freeze to ship due to voting,
> > >     tck testing and potential repeats of that process (re-cut,
> > >     re-certify, re-vote).  There is no reason why work on x.y.z+1
> > >     needs to be delayed -- only 52 weeks a year.
> > >
> > > 2.  stronger guarantee no one is updating the branch once frozen
> > >
> > > 3.  less likely that people and ci systems (continuum) will checkout
> > >     and build pre-release versions of x.y.z (not x.y.z-SNAPSHOT) which
> > >     would need to be removed manually and may accidentally be
> > >     distributed.
> > >
> > > 4.  it is currently very difficult to roll version numbers forward,
> > >     entries here and there are often missed.  Far better to have
> > >     branches/x.y have a few straggling old x.y.z-SNAPSHOT versions
> > >     than a few overlooked x.y.z final numbers that needed to go back
> > >     to SNAPSHOT -- they never leave SNAPSHOT and need to be reverted
> > >     back later if that process happens in the frozen branch.
> > >
> > >
> > > Here is my +1
> > >
> > >
> > > -- David
> > >
> > >
> > >
> > > On Jun 21, 2006, at 4:14 PM, Matt Hogstrom wrote:
> > >
> > >> After the branches/1.1 was moved to tags there was some question as
> > >> to what happened to the 1.1 branch.  At that time some kind soul
> > >> created a new branches/1.1.1.  No activity has occurred in that
> > >> branch and given that we'll need to define the release goals of 1.1.1
> > >> soon I'd like to propose the following.
> > >>
> > >> After 1.1 is released:
> > >>
> > >> * Delete branches/1.1.1
> > >> * Move branches/1.1.0 to tags/1.1.0
> > >> * Copy tags/1.1.0 to branches/1.1.1
> > >> * Update branches 1.1.1 to be 1.1.1-SNAPSHOT
> > >> * Start working on 1.1.1
> > >>
> > >> When 1.1.1 enters time for release
> > >>
> > >> * Move branches/1.1.1 to branches/1.1.1.0
> > >> * Change version from 1.1.1-SNAPSHOT to 1.1.1
> > >> * Create release candidate rc1
> > >> * put out for a vote
> > >> * get a successful vote with no respins :)
> > >> * move from branches/1.1.1.0 to tags/1.1.1.0
> > >>
> > >> Based on all the confusion in the past I think this procedure makes
> > >> it clear what phase were in for the release as well as avoids tagging
> > >> and branching repeatedly.
> > >>
> > >> I'm looking for lazy consensus and not a formal vote.
> > >>
> > >> Matt
> > >>
> > >
> >
> >
>
>
> --
> Regards,
> Hiram
>
> Blog: http://hiramchirino.com
>

Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)

[Hiram Chirino <hi...@hiramchirino.com>]

+1

On 6/21/06, Alan D. Cabrera <li...@toolazydogs.com> 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 reason why the versions
> drifted so wildly apart.
>
> Regards,
> Alan
>
> 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.   branches/x.y would be the branch for all x.y.z releases
> >
> > 2.   when a release is frozen, we spin off a branch with that *exact*
> >      name, as in branches/x.y.z, where z starts at zero and increments
> >      by one.
> >
> > 3.   at that time branches/x.y is immediately updated to version
> >      x.y.(z+1)-SNAPSHOT
> >
> > 3.   We cut releases from the frozen branch
> >
> > 4.   When a release passes final tck testing and final vote, the
> >      frozen branch is moved to tags
> >
> > We create a branch at freeze time for the following reasons:
> >
> > 1.  it takes *at least* one week from freeze to ship due to voting,
> >     tck testing and potential repeats of that process (re-cut,
> >     re-certify, re-vote).  There is no reason why work on x.y.z+1
> >     needs to be delayed -- only 52 weeks a year.
> >
> > 2.  stronger guarantee no one is updating the branch once frozen
> >
> > 3.  less likely that people and ci systems (continuum) will checkout
> >     and build pre-release versions of x.y.z (not x.y.z-SNAPSHOT) which
> >     would need to be removed manually and may accidentally be
> >     distributed.
> >
> > 4.  it is currently very difficult to roll version numbers forward,
> >     entries here and there are often missed.  Far better to have
> >     branches/x.y have a few straggling old x.y.z-SNAPSHOT versions
> >     than a few overlooked x.y.z final numbers that needed to go back
> >     to SNAPSHOT -- they never leave SNAPSHOT and need to be reverted
> >     back later if that process happens in the frozen branch.
> >
> >
> > Here is my +1
> >
> >
> > -- David
> >
> >
> >
> > On Jun 21, 2006, at 4:14 PM, Matt Hogstrom wrote:
> >
> >> After the branches/1.1 was moved to tags there was some question as
> >> to what happened to the 1.1 branch.  At that time some kind soul
> >> created a new branches/1.1.1.  No activity has occurred in that
> >> branch and given that we'll need to define the release goals of 1.1.1
> >> soon I'd like to propose the following.
> >>
> >> After 1.1 is released:
> >>
> >> * Delete branches/1.1.1
> >> * Move branches/1.1.0 to tags/1.1.0
> >> * Copy tags/1.1.0 to branches/1.1.1
> >> * Update branches 1.1.1 to be 1.1.1-SNAPSHOT
> >> * Start working on 1.1.1
> >>
> >> When 1.1.1 enters time for release
> >>
> >> * Move branches/1.1.1 to branches/1.1.1.0
> >> * Change version from 1.1.1-SNAPSHOT to 1.1.1
> >> * Create release candidate rc1
> >> * put out for a vote
> >> * get a successful vote with no respins :)
> >> * move from branches/1.1.1.0 to tags/1.1.1.0
> >>
> >> Based on all the confusion in the past I think this procedure makes
> >> it clear what phase were in for the release as well as avoids tagging
> >> and branching repeatedly.
> >>
> >> I'm looking for lazy consensus and not a formal vote.
> >>
> >> Matt
> >>
> >
>
>


-- 
Regards,
Hiram

Blog: http://hiramchirino.com

Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)

[David Jencks <da...@yahoo.com>]

+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 evenly across the board  
> when fixes were checked into one branch.  This is one reason why  
> the versions drifted so wildly apart.
>
> Regards,
> Alan
>
> 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.   branches/x.y would be the branch for all x.y.z releases
>>
>> 2.   when a release is frozen, we spin off a branch with that *exact*
>>      name, as in branches/x.y.z, where z starts at zero and  
>> increments
>>      by one.
>>
>> 3.   at that time branches/x.y is immediately updated to version
>>      x.y.(z+1)-SNAPSHOT
>>
>> 3.   We cut releases from the frozen branch
>>
>> 4.   When a release passes final tck testing and final vote, the
>>      frozen branch is moved to tags
>>
>> We create a branch at freeze time for the following reasons:
>>
>> 1.  it takes *at least* one week from freeze to ship due to voting,
>>     tck testing and potential repeats of that process (re-cut,
>>     re-certify, re-vote).  There is no reason why work on x.y.z+1
>>     needs to be delayed -- only 52 weeks a year.
>>
>> 2.  stronger guarantee no one is updating the branch once frozen
>>
>> 3.  less likely that people and ci systems (continuum) will checkout
>>     and build pre-release versions of x.y.z (not x.y.z-SNAPSHOT)  
>> which
>>     would need to be removed manually and may accidentally be
>>     distributed.
>>
>> 4.  it is currently very difficult to roll version numbers forward,
>>     entries here and there are often missed.  Far better to have
>>     branches/x.y have a few straggling old x.y.z-SNAPSHOT versions
>>     than a few overlooked x.y.z final numbers that needed to go back
>>     to SNAPSHOT -- they never leave SNAPSHOT and need to be reverted
>>     back later if that process happens in the frozen branch.
>>
>>
>> Here is my +1
>>
>>
>> -- David
>>
>>
>>
>> On Jun 21, 2006, at 4:14 PM, Matt Hogstrom wrote:
>>
>>> After the branches/1.1 was moved to tags there was some question  
>>> as to what happened to the 1.1 branch.  At that time some kind  
>>> soul created a new branches/1.1.1.  No activity has occurred in  
>>> that branch and given that we'll need to define the release goals  
>>> of 1.1.1 soon I'd like to propose the following.
>>>
>>> After 1.1 is released:
>>>
>>> * Delete branches/1.1.1
>>> * Move branches/1.1.0 to tags/1.1.0
>>> * Copy tags/1.1.0 to branches/1.1.1
>>> * Update branches 1.1.1 to be 1.1.1-SNAPSHOT
>>> * Start working on 1.1.1
>>>
>>> When 1.1.1 enters time for release
>>>
>>> * Move branches/1.1.1 to branches/1.1.1.0
>>> * Change version from 1.1.1-SNAPSHOT to 1.1.1
>>> * Create release candidate rc1
>>> * put out for a vote
>>> * get a successful vote with no respins :)
>>> * move from branches/1.1.1.0 to tags/1.1.1.0
>>>
>>> Based on all the confusion in the past I think this procedure  
>>> makes it clear what phase were in for the release as well as  
>>> avoids tagging and branching repeatedly.
>>>
>>> I'm looking for lazy consensus and not a formal vote.
>>>
>>> Matt
>>>
>>
>

Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)

["Alan D. Cabrera" <li...@toolazydogs.com>]

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

Regards,
Alan

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.   branches/x.y would be the branch for all x.y.z releases
>
> 2.   when a release is frozen, we spin off a branch with that *exact*
>      name, as in branches/x.y.z, where z starts at zero and increments
>      by one.
>
> 3.   at that time branches/x.y is immediately updated to version
>      x.y.(z+1)-SNAPSHOT
>
> 3.   We cut releases from the frozen branch
>
> 4.   When a release passes final tck testing and final vote, the
>      frozen branch is moved to tags
>
> We create a branch at freeze time for the following reasons:
>
> 1.  it takes *at least* one week from freeze to ship due to voting,
>     tck testing and potential repeats of that process (re-cut,
>     re-certify, re-vote).  There is no reason why work on x.y.z+1
>     needs to be delayed -- only 52 weeks a year.
>
> 2.  stronger guarantee no one is updating the branch once frozen
>
> 3.  less likely that people and ci systems (continuum) will checkout
>     and build pre-release versions of x.y.z (not x.y.z-SNAPSHOT) which
>     would need to be removed manually and may accidentally be
>     distributed.
>
> 4.  it is currently very difficult to roll version numbers forward,
>     entries here and there are often missed.  Far better to have
>     branches/x.y have a few straggling old x.y.z-SNAPSHOT versions
>     than a few overlooked x.y.z final numbers that needed to go back
>     to SNAPSHOT -- they never leave SNAPSHOT and need to be reverted
>     back later if that process happens in the frozen branch.
>
>
> Here is my +1
>
>
> -- David
>
>
>
> On Jun 21, 2006, at 4:14 PM, Matt Hogstrom wrote:
>
>> After the branches/1.1 was moved to tags there was some question as 
>> to what happened to the 1.1 branch.  At that time some kind soul 
>> created a new branches/1.1.1.  No activity has occurred in that 
>> branch and given that we'll need to define the release goals of 1.1.1 
>> soon I'd like to propose the following.
>>
>> After 1.1 is released:
>>
>> * Delete branches/1.1.1
>> * Move branches/1.1.0 to tags/1.1.0
>> * Copy tags/1.1.0 to branches/1.1.1
>> * Update branches 1.1.1 to be 1.1.1-SNAPSHOT
>> * Start working on 1.1.1
>>
>> When 1.1.1 enters time for release
>>
>> * Move branches/1.1.1 to branches/1.1.1.0
>> * Change version from 1.1.1-SNAPSHOT to 1.1.1
>> * Create release candidate rc1
>> * put out for a vote
>> * get a successful vote with no respins :)
>> * move from branches/1.1.1.0 to tags/1.1.1.0
>>
>> Based on all the confusion in the past I think this procedure makes 
>> it clear what phase were in for the release as well as avoids tagging 
>> and branching repeatedly.
>>
>> I'm looking for lazy consensus and not a formal vote.
>>
>> Matt
>>
>

Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)

[Jacek Laskowski <ja...@laskowski.net.pl>]

On 6/22/06, David Blevins <da...@visi.com> wrote:

> Definitely, was waiting to see some +1s before doing that part.
>
> Here it is:
>
> http://cwiki.apache.org/GMOxPMGT/release-branching-process.html

+1 (with the overly used 'That reflects my sentiments as well' :-) )

> -David

Jacek

-- 
Jacek Laskowski
http://www.laskowski.net.pl

Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)

[David Blevins <da...@visi.com>]

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:

http://cwiki.apache.org/GMOxPMGT/release-branching-process.html

-David


> 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.   branches/x.y would be the branch for all x.y.z releases
>>
>> 2.   when a release is frozen, we spin off a branch with that *exact*
>>      name, as in branches/x.y.z, where z starts at zero and  
>> increments
>>      by one.
>>
>> 3.   at that time branches/x.y is immediately updated to version
>>      x.y.(z+1)-SNAPSHOT
>>
>> 3.   We cut releases from the frozen branch
>>
>> 4.   When a release passes final tck testing and final vote, the
>>      frozen branch is moved to tags
>>
>> We create a branch at freeze time for the following reasons:
>>
>> 1.  it takes *at least* one week from freeze to ship due to voting,
>>     tck testing and potential repeats of that process (re-cut,
>>     re-certify, re-vote).  There is no reason why work on x.y.z+1
>>     needs to be delayed -- only 52 weeks a year.
>>
>> 2.  stronger guarantee no one is updating the branch once frozen
>>
>> 3.  less likely that people and ci systems (continuum) will checkout
>>     and build pre-release versions of x.y.z (not x.y.z-SNAPSHOT)  
>> which
>>     would need to be removed manually and may accidentally be
>>     distributed.
>>
>> 4.  it is currently very difficult to roll version numbers forward,
>>     entries here and there are often missed.  Far better to have
>>     branches/x.y have a few straggling old x.y.z-SNAPSHOT versions
>>     than a few overlooked x.y.z final numbers that needed to go back
>>     to SNAPSHOT -- they never leave SNAPSHOT and need to be reverted
>>     back later if that process happens in the frozen branch.
>>
>>
>> Here is my +1
>>
>>
>> -- David
>>
>>
>>
>> On Jun 21, 2006, at 4:14 PM, Matt Hogstrom wrote:
>>
>>> After the branches/1.1 was moved to tags there was some question  
>>> as to what happened to the 1.1 branch.  At that time some kind  
>>> soul created a new branches/1.1.1.  No activity has occurred in  
>>> that branch and given that we'll need to define the release goals  
>>> of 1.1.1 soon I'd like to propose the following.
>>>
>>> After 1.1 is released:
>>>
>>> * Delete branches/1.1.1
>>> * Move branches/1.1.0 to tags/1.1.0
>>> * Copy tags/1.1.0 to branches/1.1.1
>>> * Update branches 1.1.1 to be 1.1.1-SNAPSHOT
>>> * Start working on 1.1.1
>>>
>>> When 1.1.1 enters time for release
>>>
>>> * Move branches/1.1.1 to branches/1.1.1.0
>>> * Change version from 1.1.1-SNAPSHOT to 1.1.1
>>> * Create release candidate rc1
>>> * put out for a vote
>>> * get a successful vote with no respins :)
>>> * move from branches/1.1.1.0 to tags/1.1.1.0
>>>
>>> Based on all the confusion in the past I think this procedure  
>>> makes it clear what phase were in for the release as well as  
>>> avoids tagging and branching repeatedly.
>>>
>>> I'm looking for lazy consensus and not a formal vote.
>>>
>>> Matt
>>>
>>
>>
>

Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)

[Rick McGuire <ri...@gmail.com>]

+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 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 branch for all x.y.z releases
>
> 2.   when a release is frozen, we spin off a branch with that *exact*
>      name, as in branches/x.y.z, where z starts at zero and increments
>      by one.
>
> 3.   at that time branches/x.y is immediately updated to version
>      x.y.(z+1)-SNAPSHOT
>
> 3.   We cut releases from the frozen branch
>
> 4.   When a release passes final tck testing and final vote, the
>      frozen branch is moved to tags
>
> We create a branch at freeze time for the following reasons:
>
> 1.  it takes *at least* one week from freeze to ship due to voting,
>     tck testing and potential repeats of that process (re-cut,
>     re-certify, re-vote).  There is no reason why work on x.y.z+1
>     needs to be delayed -- only 52 weeks a year.
>
> 2.  stronger guarantee no one is updating the branch once frozen
>
> 3.  less likely that people and ci systems (continuum) will checkout
>     and build pre-release versions of x.y.z (not x.y.z-SNAPSHOT) which
>     would need to be removed manually and may accidentally be
>     distributed.
>
> 4.  it is currently very difficult to roll version numbers forward,
>     entries here and there are often missed.  Far better to have
>     branches/x.y have a few straggling old x.y.z-SNAPSHOT versions
>     than a few overlooked x.y.z final numbers that needed to go back
>     to SNAPSHOT -- they never leave SNAPSHOT and need to be reverted
>     back later if that process happens in the frozen branch.
>
>
> Here is my +1
>
>
> -- David
>
>
>
> On Jun 21, 2006, at 4:14 PM, Matt Hogstrom wrote:
>
>> After the branches/1.1 was moved to tags there was some question as 
>> to what happened to the 1.1 branch.  At that time some kind soul 
>> created a new branches/1.1.1.  No activity has occurred in that 
>> branch and given that we'll need to define the release goals of 1.1.1 
>> soon I'd like to propose the following.
>>
>> After 1.1 is released:
>>
>> * Delete branches/1.1.1
>> * Move branches/1.1.0 to tags/1.1.0
>> * Copy tags/1.1.0 to branches/1.1.1
>> * Update branches 1.1.1 to be 1.1.1-SNAPSHOT
>> * Start working on 1.1.1
>>
>> When 1.1.1 enters time for release
>>
>> * Move branches/1.1.1 to branches/1.1.1.0
>> * Change version from 1.1.1-SNAPSHOT to 1.1.1
>> * Create release candidate rc1
>> * put out for a vote
>> * get a successful vote with no respins :)
>> * move from branches/1.1.1.0 to tags/1.1.1.0
>>
>> Based on all the confusion in the past I think this procedure makes 
>> it clear what phase were in for the release as well as avoids tagging 
>> and branching repeatedly.
>>
>> I'm looking for lazy consensus and not a formal vote.
>>
>> Matt
>>
>
>

Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)

[Gianny Damour <gi...@optusnet.com.au>]

+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.   branches/x.y would be the branch for all x.y.z releases
>
> 2.   when a release is frozen, we spin off a branch with that *exact*
>      name, as in branches/x.y.z, where z starts at zero and increments
>      by one.
>
> 3.   at that time branches/x.y is immediately updated to version
>      x.y.(z+1)-SNAPSHOT
>
> 3.   We cut releases from the frozen branch
>
> 4.   When a release passes final tck testing and final vote, the
>      frozen branch is moved to tags
>
> We create a branch at freeze time for the following reasons:
>
> 1.  it takes *at least* one week from freeze to ship due to voting,
>     tck testing and potential repeats of that process (re-cut,
>     re-certify, re-vote).  There is no reason why work on x.y.z+1
>     needs to be delayed -- only 52 weeks a year.
>
> 2.  stronger guarantee no one is updating the branch once frozen
>
> 3.  less likely that people and ci systems (continuum) will checkout
>     and build pre-release versions of x.y.z (not x.y.z-SNAPSHOT) which
>     would need to be removed manually and may accidentally be
>     distributed.
>
> 4.  it is currently very difficult to roll version numbers forward,
>     entries here and there are often missed.  Far better to have
>     branches/x.y have a few straggling old x.y.z-SNAPSHOT versions
>     than a few overlooked x.y.z final numbers that needed to go back
>     to SNAPSHOT -- they never leave SNAPSHOT and need to be reverted
>     back later if that process happens in the frozen branch.
>
>
> Here is my +1
>
>
> --  David
>
>
>
> On Jun 21, 2006, at 4:14 PM, Matt Hogstrom wrote:
>
>> After the branches/1.1 was moved to tags there was some question as  
>> to what happened to the 1.1 branch.  At that time some kind soul  
>> created a new branches/1.1.1.  No activity has occurred in that  
>> branch and given that we'll need to define the release goals of  
>> 1.1.1 soon I'd like to propose the following.
>>
>> After 1.1 is released:
>>
>> * Delete branches/1.1.1
>> * Move branches/1.1.0 to tags/1.1.0
>> * Copy tags/1.1.0 to branches/1.1.1
>> * Update branches 1.1.1 to be 1.1.1-SNAPSHOT
>> * Start working on 1.1.1
>>
>> When 1.1.1 enters time for release
>>
>> * Move branches/1.1.1 to branches/1.1.1.0
>> * Change version from 1.1.1-SNAPSHOT to 1.1.1
>> * Create release candidate rc1
>> * put out for a vote
>> * get a successful vote with no respins :)
>> * move from branches/1.1.1.0 to tags/1.1.1.0
>>
>> Based on all the confusion in the past I think this procedure makes  
>> it clear what phase were in for the release as well as avoids  
>> tagging and branching repeatedly.
>>
>> I'm looking for lazy consensus and not a formal vote.
>>
>> Matt
>>
>
>
>

Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)

["Alan D. Cabrera" <li...@toolazydogs.com>]

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 next x.y.z release)
>>
>>
>> Fixes
>>
>> develop in x.y branch (if to be captured in next x.y.z release else 
>> develop in trunk)
>> patch to trunk
>> patch to current x.y.z (if it is a TCK bug).
>
> This is good discussion.  In the interests of seeing it continue while 
> keeping clear what we've voted on and what is still open for 
> discussion, i've split this out into a new wiki page titled with the 
> soft word "guidelines."
>
> http://cwiki.apache.org/GMOxPMGT/development-and-patch-guidelines.html
>
> Further, i've added a "Notice" section at the bottom of this page that 
> states,  "The process in this document was voted on by the Geronimo 
> community. Please formally propose all changes to 
> dev@geronimo.apache.org"
>
> http://cwiki.apache.org/GMOxPMGT/release-branching-process.html

Makes sense.  Thanks David.


Regards,
Alan

Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)

[Matt Hogstrom <ma...@hogstrom.org>]

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 be captured in next x.y.z release)
>>
>>
>> Fixes
>>
>> develop in x.y branch (if to be captured in next x.y.z release else 
>> develop in trunk)
>> patch to trunk
>> patch to current x.y.z (if it is a TCK bug).
> 
> This is good discussion.  In the interests of seeing it continue while 
> keeping clear what we've voted on and what is still open for discussion, 
> i've split this out into a new wiki page titled with the soft word 
> "guidelines."
> 
> http://cwiki.apache.org/GMOxPMGT/development-and-patch-guidelines.html
> 
> Further, i've added a "Notice" section at the bottom of this page that 
> states,  "The process in this document was voted on by the Geronimo 
> community. Please formally propose all changes to dev@geronimo.apache.org"
> 
> http://cwiki.apache.org/GMOxPMGT/release-branching-process.html
> 
> 
> -David
> 
> 
>>
>> Regards,
>> Alan
>>
>>
> 
> 
> 
> 

Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)

[David Blevins <da...@visi.com>]

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 next x.y.z release)
>
>
> Fixes
>
> develop in x.y branch (if to be captured in next x.y.z release else  
> develop in trunk)
> patch to trunk
> patch to current x.y.z (if it is a TCK bug).

This is good discussion.  In the interests of seeing it continue  
while keeping clear what we've voted on and what is still open for  
discussion, i've split this out into a new wiki page titled with the  
soft word "guidelines."

http://cwiki.apache.org/GMOxPMGT/development-and-patch-guidelines.html

Further, i've added a "Notice" section at the bottom of this page  
that states,  "The process in this document was voted on by the  
Geronimo community. Please formally propose all changes to  
dev@geronimo.apache.org"

http://cwiki.apache.org/GMOxPMGT/release-branching-process.html


-David


>
> Regards,
> Alan
>
>

Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)

["Alan D. Cabrera" <li...@toolazydogs.com>]

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 next x.y.z release else 
develop in trunk)
patch to trunk
patch to current x.y.z (if it is a TCK bug).


Regards,
Alan

Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)

[Greg Wilkins <gr...@mortbay.com>]

+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 Features:

    develop in trunk
    patch to current x.y branch
    captured in next x.y.z


  Fixes

    develop in x.y  branch
    patch to trunk
    patch to current x.y.z  (if NOT frozen yet).



cheers

 

Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)

[David Blevins <da...@visi.com>]

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 and we release 1.1 I'll move  
> branches/1.1.0 to tags/1.1.0 and then make the copy to branches/1.1  
> and update the versions to 1.1.1-SNAPSHOT as well as the plugin  
> releases.

I whacked branches/1.1.1 -- that was my mess.  We're good on branches/ 
1.1, it was created from 1.1.0.  There was an update to the 1.1.0  
NOTICE.txt file which is the only thing we have to port back.
>
> Then I think we're open for G-Business.

G-reat.

/me is getting a very Tony the Tiger vibe

-David

Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)

[Hiram Chirino <hi...@hiramchirino.com>]

On 6/22/06, Matt Hogstrom <ma...@hogstrom.org> 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 is my + 1 and I'm happy to get the Wiki updated.
>
> 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 and we release 1.1 I'll move branches/1.1.0 to tags/1.1.0
> and then make the copy to branches/1.1 and update the versions to 1.1.1-SNAPSHOT as well as the
> plugin releases.

+1

>
> Then I think we're open for G-Business.
>
> 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.   branches/x.y would be the branch for all x.y.z releases
> >
> > 2.   when a release is frozen, we spin off a branch with that *exact*
> >      name, as in branches/x.y.z, where z starts at zero and increments
> >      by one.
> >
> > 3.   at that time branches/x.y is immediately updated to version
> >      x.y.(z+1)-SNAPSHOT
> >
> > 3.   We cut releases from the frozen branch
> >
> > 4.   When a release passes final tck testing and final vote, the
> >      frozen branch is moved to tags
> >
> > We create a branch at freeze time for the following reasons:
> >
> > 1.  it takes *at least* one week from freeze to ship due to voting,
> >     tck testing and potential repeats of that process (re-cut,
> >     re-certify, re-vote).  There is no reason why work on x.y.z+1
> >     needs to be delayed -- only 52 weeks a year.
> >
> > 2.  stronger guarantee no one is updating the branch once frozen
> >
> > 3.  less likely that people and ci systems (continuum) will checkout
> >     and build pre-release versions of x.y.z (not x.y.z-SNAPSHOT) which
> >     would need to be removed manually and may accidentally be
> >     distributed.
> >
> > 4.  it is currently very difficult to roll version numbers forward,
> >     entries here and there are often missed.  Far better to have
> >     branches/x.y have a few straggling old x.y.z-SNAPSHOT versions
> >     than a few overlooked x.y.z final numbers that needed to go back
> >     to SNAPSHOT -- they never leave SNAPSHOT and need to be reverted
> >     back later if that process happens in the frozen branch.
> >
> >
> > Here is my +1
> >
> >
> > -- David
> >
> >
> >
> > On Jun 21, 2006, at 4:14 PM, Matt Hogstrom wrote:
> >
> >> After the branches/1.1 was moved to tags there was some question as to
> >> what happened to the 1.1 branch.  At that time some kind soul created
> >> a new branches/1.1.1.  No activity has occurred in that branch and
> >> given that we'll need to define the release goals of 1.1.1 soon I'd
> >> like to propose the following.
> >>
> >> After 1.1 is released:
> >>
> >> * Delete branches/1.1.1
> >> * Move branches/1.1.0 to tags/1.1.0
> >> * Copy tags/1.1.0 to branches/1.1.1
> >> * Update branches 1.1.1 to be 1.1.1-SNAPSHOT
> >> * Start working on 1.1.1
> >>
> >> When 1.1.1 enters time for release
> >>
> >> * Move branches/1.1.1 to branches/1.1.1.0
> >> * Change version from 1.1.1-SNAPSHOT to 1.1.1
> >> * Create release candidate rc1
> >> * put out for a vote
> >> * get a successful vote with no respins :)
> >> * move from branches/1.1.1.0 to tags/1.1.1.0
> >>
> >> Based on all the confusion in the past I think this procedure makes it
> >> clear what phase were in for the release as well as avoids tagging and
> >> branching repeatedly.
> >>
> >> I'm looking for lazy consensus and not a formal vote.
> >>
> >> Matt
> >>
> >
> >
> >
> >
>


-- 
Regards,
Hiram

Blog: http://hiramchirino.com

Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)

[Jason Dillon <ja...@planet57.com>]

> Then I think we're open for G-Business.

I love it... G-Business :-)

--jason

Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)

[John Sisson <jr...@gmail.com>]

+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 great and I concur.
>
> Here is my + 1 and I'm happy to get the Wiki updated.
>
> 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 and we release 1.1 I'll move 
> branches/1.1.0 to tags/1.1.0 and then make the copy to branches/1.1 
> and update the versions to 1.1.1-SNAPSHOT as well as the plugin releases.
>
> Then I think we're open for G-Business.
>
> 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.   branches/x.y would be the branch for all x.y.z releases
>>
>> 2.   when a release is frozen, we spin off a branch with that *exact*
>>      name, as in branches/x.y.z, where z starts at zero and increments
>>      by one.
>>
>> 3.   at that time branches/x.y is immediately updated to version
>>      x.y.(z+1)-SNAPSHOT
>>
>> 3.   We cut releases from the frozen branch
>>
>> 4.   When a release passes final tck testing and final vote, the
>>      frozen branch is moved to tags
>>
>> We create a branch at freeze time for the following reasons:
>>
>> 1.  it takes *at least* one week from freeze to ship due to voting,
>>     tck testing and potential repeats of that process (re-cut,
>>     re-certify, re-vote).  There is no reason why work on x.y.z+1
>>     needs to be delayed -- only 52 weeks a year.
>>
>> 2.  stronger guarantee no one is updating the branch once frozen
>>
>> 3.  less likely that people and ci systems (continuum) will checkout
>>     and build pre-release versions of x.y.z (not x.y.z-SNAPSHOT) which
>>     would need to be removed manually and may accidentally be
>>     distributed.
>>
>> 4.  it is currently very difficult to roll version numbers forward,
>>     entries here and there are often missed.  Far better to have
>>     branches/x.y have a few straggling old x.y.z-SNAPSHOT versions
>>     than a few overlooked x.y.z final numbers that needed to go back
>>     to SNAPSHOT -- they never leave SNAPSHOT and need to be reverted
>>     back later if that process happens in the frozen branch.
>>
>>
>> Here is my +1
>>
>>
>> -- David
>>
>>
>>
>> On Jun 21, 2006, at 4:14 PM, Matt Hogstrom wrote:
>>
>>> After the branches/1.1 was moved to tags there was some question as 
>>> to what happened to the 1.1 branch.  At that time some kind soul 
>>> created a new branches/1.1.1.  No activity has occurred in that 
>>> branch and given that we'll need to define the release goals of 
>>> 1.1.1 soon I'd like to propose the following.
>>>
>>> After 1.1 is released:
>>>
>>> * Delete branches/1.1.1
>>> * Move branches/1.1.0 to tags/1.1.0
>>> * Copy tags/1.1.0 to branches/1.1.1
>>> * Update branches 1.1.1 to be 1.1.1-SNAPSHOT
>>> * Start working on 1.1.1
>>>
>>> When 1.1.1 enters time for release
>>>
>>> * Move branches/1.1.1 to branches/1.1.1.0
>>> * Change version from 1.1.1-SNAPSHOT to 1.1.1
>>> * Create release candidate rc1
>>> * put out for a vote
>>> * get a successful vote with no respins :)
>>> * move from branches/1.1.1.0 to tags/1.1.1.0
>>>
>>> Based on all the confusion in the past I think this procedure makes 
>>> it clear what phase were in for the release as well as avoids 
>>> tagging and branching repeatedly.
>>>
>>> I'm looking for lazy consensus and not a formal vote.
>>>
>>> Matt
>>>
>>
>>
>>
>>
>

Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)

[Matt Hogstrom <ma...@hogstrom.org>]

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.

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 and we release 1.1 I'll move branches/1.1.0 to tags/1.1.0 
and then make the copy to branches/1.1 and update the versions to 1.1.1-SNAPSHOT as well as the 
plugin releases.

Then I think we're open for G-Business.

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.   branches/x.y would be the branch for all x.y.z releases
> 
> 2.   when a release is frozen, we spin off a branch with that *exact*
>      name, as in branches/x.y.z, where z starts at zero and increments
>      by one.
> 
> 3.   at that time branches/x.y is immediately updated to version
>      x.y.(z+1)-SNAPSHOT
> 
> 3.   We cut releases from the frozen branch
> 
> 4.   When a release passes final tck testing and final vote, the
>      frozen branch is moved to tags
> 
> We create a branch at freeze time for the following reasons:
> 
> 1.  it takes *at least* one week from freeze to ship due to voting,
>     tck testing and potential repeats of that process (re-cut,
>     re-certify, re-vote).  There is no reason why work on x.y.z+1
>     needs to be delayed -- only 52 weeks a year.
> 
> 2.  stronger guarantee no one is updating the branch once frozen
> 
> 3.  less likely that people and ci systems (continuum) will checkout
>     and build pre-release versions of x.y.z (not x.y.z-SNAPSHOT) which
>     would need to be removed manually and may accidentally be
>     distributed.
> 
> 4.  it is currently very difficult to roll version numbers forward,
>     entries here and there are often missed.  Far better to have
>     branches/x.y have a few straggling old x.y.z-SNAPSHOT versions
>     than a few overlooked x.y.z final numbers that needed to go back
>     to SNAPSHOT -- they never leave SNAPSHOT and need to be reverted
>     back later if that process happens in the frozen branch.
> 
> 
> Here is my +1
> 
> 
> -- David
> 
> 
> 
> On Jun 21, 2006, at 4:14 PM, Matt Hogstrom wrote:
> 
>> After the branches/1.1 was moved to tags there was some question as to 
>> what happened to the 1.1 branch.  At that time some kind soul created 
>> a new branches/1.1.1.  No activity has occurred in that branch and 
>> given that we'll need to define the release goals of 1.1.1 soon I'd 
>> like to propose the following.
>>
>> After 1.1 is released:
>>
>> * Delete branches/1.1.1
>> * Move branches/1.1.0 to tags/1.1.0
>> * Copy tags/1.1.0 to branches/1.1.1
>> * Update branches 1.1.1 to be 1.1.1-SNAPSHOT
>> * Start working on 1.1.1
>>
>> When 1.1.1 enters time for release
>>
>> * Move branches/1.1.1 to branches/1.1.1.0
>> * Change version from 1.1.1-SNAPSHOT to 1.1.1
>> * Create release candidate rc1
>> * put out for a vote
>> * get a successful vote with no respins :)
>> * move from branches/1.1.1.0 to tags/1.1.1.0
>>
>> Based on all the confusion in the past I think this procedure makes it 
>> clear what phase were in for the release as well as avoids tagging and 
>> branching repeatedly.
>>
>> I'm looking for lazy consensus and not a formal vote.
>>
>> Matt
>>
> 
> 
> 
> 

Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)

["Alan D. Cabrera" <li...@toolazydogs.com>]

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 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 branch for all x.y.z releases
>>
>> 2.   when a release is frozen, we spin off a branch with that *exact*
>>      name, as in branches/x.y.z, where z starts at zero and increments
>>      by one.
>>
>> 3.   at that time branches/x.y is immediately updated to version
>>      x.y.(z+1)-SNAPSHOT
>>
>> 3.   We cut releases from the frozen branch
>>
>> 4.   When a release passes final tck testing and final vote, the
>>      frozen branch is moved to tags
>>
>> We create a branch at freeze time for the following reasons:
>>
>> 1.  it takes *at least* one week from freeze to ship due to voting,
>>     tck testing and potential repeats of that process (re-cut,
>>     re-certify, re-vote).  There is no reason why work on x.y.z+1
>>     needs to be delayed -- only 52 weeks a year.
>>
>> 2.  stronger guarantee no one is updating the branch once frozen
>>
>> 3.  less likely that people and ci systems (continuum) will checkout
>>     and build pre-release versions of x.y.z (not x.y.z-SNAPSHOT) which
>>     would need to be removed manually and may accidentally be
>>     distributed.
>>
>> 4.  it is currently very difficult to roll version numbers forward,
>>     entries here and there are often missed.  Far better to have
>>     branches/x.y have a few straggling old x.y.z-SNAPSHOT versions
>>     than a few overlooked x.y.z final numbers that needed to go back
>>     to SNAPSHOT -- they never leave SNAPSHOT and need to be reverted
>>     back later if that process happens in the frozen branch.
>>
>>
>> Here is my +1
>>
>>
>> -- David
>>
>>
>>
>> On Jun 21, 2006, at 4:14 PM, Matt Hogstrom wrote:
>>
>>> After the branches/1.1 was moved to tags there was some question as 
>>> to what happened to the 1.1 branch.  At that time some kind soul 
>>> created a new branches/1.1.1.  No activity has occurred in that 
>>> branch and given that we'll need to define the release goals of 
>>> 1.1.1 soon I'd like to propose the following.
>>>
>>> After 1.1 is released:
>>>
>>> * Delete branches/1.1.1
>>> * Move branches/1.1.0 to tags/1.1.0
>>> * Copy tags/1.1.0 to branches/1.1.1
>>> * Update branches 1.1.1 to be 1.1.1-SNAPSHOT
>>> * Start working on 1.1.1
>>>
>>> When 1.1.1 enters time for release
>>>
>>> * Move branches/1.1.1 to branches/1.1.1.0
>>> * Change version from 1.1.1-SNAPSHOT to 1.1.1
>>> * Create release candidate rc1
>>> * put out for a vote
>>> * get a successful vote with no respins :)
>>> * move from branches/1.1.1.0 to tags/1.1.1.0
>>>
>>> Based on all the confusion in the past I think this procedure makes 
>>> it clear what phase were in for the release as well as avoids 
>>> tagging and branching repeatedly.
>>>
>>> I'm looking for lazy consensus and not a formal vote.
>>>
>>> Matt
>>>
>>
>

Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)

["Alan D. Cabrera" <li...@toolazydogs.com>]

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 numbers, etc.  The 
> "button it up" stuff.  Specifically trying to exclude thinks like 
> "let's fix these 20 bugs."  The only bugs fixed would be in the event 
> the release candidate had an unacceptable issue and it's vote did not 
> pass.  That's the spirit of it anyway.

Thanks that clears it up for me.  Agreed.


Regards,
Alan

Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)

[David Blevins <da...@visi.com>]

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  
"button it up" stuff.  Specifically trying to exclude thinks like  
"let's fix these 20 bugs."  The only bugs fixed would be in the event  
the release candidate had an unacceptable issue and it's vote did not  
pass.  That's the spirit of it anyway.

-David


>> 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  
>> vote passes.  That's the ideal scenario anyway.
>>
>> -David
>>
>> On Jun 21, 2006, at 9:40 PM, 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 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 branch for all x.y.z releases
>>>>
>>>> 2.   when a release is frozen, we spin off a branch with that  
>>>> *exact*
>>>>      name, as in branches/x.y.z, where z starts at zero and  
>>>> increments
>>>>      by one.
>>>>
>>>> 3.   at that time branches/x.y is immediately updated to version
>>>>      x.y.(z+1)-SNAPSHOT
>>>>
>>>> 3.   We cut releases from the frozen branch
>>>>
>>>> 4.   When a release passes final tck testing and final vote, the
>>>>      frozen branch is moved to tags
>>>>
>>>> We create a branch at freeze time for the following reasons:
>>>>
>>>> 1.  it takes *at least* one week from freeze to ship due to voting,
>>>>     tck testing and potential repeats of that process (re-cut,
>>>>     re-certify, re-vote).  There is no reason why work on x.y.z+1
>>>>     needs to be delayed -- only 52 weeks a year.
>>>>
>>>> 2.  stronger guarantee no one is updating the branch once frozen
>>>>
>>>> 3.  less likely that people and ci systems (continuum) will  
>>>> checkout
>>>>     and build pre-release versions of x.y.z (not x.y.z-SNAPSHOT)  
>>>> which
>>>>     would need to be removed manually and may accidentally be
>>>>     distributed.
>>>>
>>>> 4.  it is currently very difficult to roll version numbers forward,
>>>>     entries here and there are often missed.  Far better to have
>>>>     branches/x.y have a few straggling old x.y.z-SNAPSHOT versions
>>>>     than a few overlooked x.y.z final numbers that needed to go  
>>>> back
>>>>     to SNAPSHOT -- they never leave SNAPSHOT and need to be  
>>>> reverted
>>>>     back later if that process happens in the frozen branch.
>>>>
>>>>
>>>> Here is my +1
>>>>
>>>>
>>>> -- David
>>>>
>>>>
>>>>
>>>> On Jun 21, 2006, at 4:14 PM, Matt Hogstrom wrote:
>>>>
>>>>> After the branches/1.1 was moved to tags there was some  
>>>>> question as to what happened to the 1.1 branch.  At that time  
>>>>> some kind soul created a new branches/1.1.1.  No activity has  
>>>>> occurred in that branch and given that we'll need to define the  
>>>>> release goals of 1.1.1 soon I'd like to propose the following.
>>>>>
>>>>> After 1.1 is released:
>>>>>
>>>>> * Delete branches/1.1.1
>>>>> * Move branches/1.1.0 to tags/1.1.0
>>>>> * Copy tags/1.1.0 to branches/1.1.1
>>>>> * Update branches 1.1.1 to be 1.1.1-SNAPSHOT
>>>>> * Start working on 1.1.1
>>>>>
>>>>> When 1.1.1 enters time for release
>>>>>
>>>>> * Move branches/1.1.1 to branches/1.1.1.0
>>>>> * Change version from 1.1.1-SNAPSHOT to 1.1.1
>>>>> * Create release candidate rc1
>>>>> * put out for a vote
>>>>> * get a successful vote with no respins :)
>>>>> * move from branches/1.1.1.0 to tags/1.1.1.0
>>>>>
>>>>> Based on all the confusion in the past I think this procedure  
>>>>> makes it clear what phase were in for the release as well as  
>>>>> avoids tagging and branching repeatedly.
>>>>>
>>>>> I'm looking for lazy consensus and not a formal vote.
>>>>>
>>>>> Matt
>>>>>
>>>>
>>>
>>
>

Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)

["Alan D. Cabrera" <li...@toolazydogs.com>]

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 point of the 
> freeze the release manager owns the branches/x.y.z till the vote 
> passes.  That's the ideal scenario anyway.
>
> -David
>
> On Jun 21, 2006, at 9:40 PM, 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 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 branch for all x.y.z releases
>>>
>>> 2.   when a release is frozen, we spin off a branch with that *exact*
>>>      name, as in branches/x.y.z, where z starts at zero and increments
>>>      by one.
>>>
>>> 3.   at that time branches/x.y is immediately updated to version
>>>      x.y.(z+1)-SNAPSHOT
>>>
>>> 3.   We cut releases from the frozen branch
>>>
>>> 4.   When a release passes final tck testing and final vote, the
>>>      frozen branch is moved to tags
>>>
>>> We create a branch at freeze time for the following reasons:
>>>
>>> 1.  it takes *at least* one week from freeze to ship due to voting,
>>>     tck testing and potential repeats of that process (re-cut,
>>>     re-certify, re-vote).  There is no reason why work on x.y.z+1
>>>     needs to be delayed -- only 52 weeks a year.
>>>
>>> 2.  stronger guarantee no one is updating the branch once frozen
>>>
>>> 3.  less likely that people and ci systems (continuum) will checkout
>>>     and build pre-release versions of x.y.z (not x.y.z-SNAPSHOT) which
>>>     would need to be removed manually and may accidentally be
>>>     distributed.
>>>
>>> 4.  it is currently very difficult to roll version numbers forward,
>>>     entries here and there are often missed.  Far better to have
>>>     branches/x.y have a few straggling old x.y.z-SNAPSHOT versions
>>>     than a few overlooked x.y.z final numbers that needed to go back
>>>     to SNAPSHOT -- they never leave SNAPSHOT and need to be reverted
>>>     back later if that process happens in the frozen branch.
>>>
>>>
>>> Here is my +1
>>>
>>>
>>> -- David
>>>
>>>
>>>
>>> On Jun 21, 2006, at 4:14 PM, Matt Hogstrom wrote:
>>>
>>>> After the branches/1.1 was moved to tags there was some question as 
>>>> to what happened to the 1.1 branch.  At that time some kind soul 
>>>> created a new branches/1.1.1.  No activity has occurred in that 
>>>> branch and given that we'll need to define the release goals of 
>>>> 1.1.1 soon I'd like to propose the following.
>>>>
>>>> After 1.1 is released:
>>>>
>>>> * Delete branches/1.1.1
>>>> * Move branches/1.1.0 to tags/1.1.0
>>>> * Copy tags/1.1.0 to branches/1.1.1
>>>> * Update branches 1.1.1 to be 1.1.1-SNAPSHOT
>>>> * Start working on 1.1.1
>>>>
>>>> When 1.1.1 enters time for release
>>>>
>>>> * Move branches/1.1.1 to branches/1.1.1.0
>>>> * Change version from 1.1.1-SNAPSHOT to 1.1.1
>>>> * Create release candidate rc1
>>>> * put out for a vote
>>>> * get a successful vote with no respins :)
>>>> * move from branches/1.1.1.0 to tags/1.1.1.0
>>>>
>>>> Based on all the confusion in the past I think this procedure makes 
>>>> it clear what phase were in for the release as well as avoids 
>>>> tagging and branching repeatedly.
>>>>
>>>> I'm looking for lazy consensus and not a formal vote.
>>>>
>>>> Matt
>>>>
>>>
>>
>

Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)

[Matt Hogstrom <ma...@hogstrom.org>]

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 
has been cast.

Aaron Mulder wrote:
> +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 another release candidate turns out to be
> necessary.
> 
> Thanks,
>    Aaron
> 
> On 6/22/06, Jason Dillon <ja...@planet57.com> wrote:
>> 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 the point of the freeze the release manager owns the
>> > branches/x.y.z till the vote passes.  That's the ideal scenario
>> > anyway.
>> >
>> > -David
>> >
>> > On Jun 21, 2006, at 9:40 PM, 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 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 branch for all x.y.z releases
>> >>>
>> >>> 2.   when a release is frozen, we spin off a branch with that
>> >>> *exact*
>> >>>      name, as in branches/x.y.z, where z starts at zero and
>> >>> increments
>> >>>      by one.
>> >>>
>> >>> 3.   at that time branches/x.y is immediately updated to version
>> >>>      x.y.(z+1)-SNAPSHOT
>> >>>
>> >>> 3.   We cut releases from the frozen branch
>> >>>
>> >>> 4.   When a release passes final tck testing and final vote, the
>> >>>      frozen branch is moved to tags
>> >>>
>> >>> We create a branch at freeze time for the following reasons:
>> >>>
>> >>> 1.  it takes *at least* one week from freeze to ship due to voting,
>> >>>     tck testing and potential repeats of that process (re-cut,
>> >>>     re-certify, re-vote).  There is no reason why work on x.y.z+1
>> >>>     needs to be delayed -- only 52 weeks a year.
>> >>>
>> >>> 2.  stronger guarantee no one is updating the branch once frozen
>> >>>
>> >>> 3.  less likely that people and ci systems (continuum) will checkout
>> >>>     and build pre-release versions of x.y.z (not x.y.z-SNAPSHOT)
>> >>> which
>> >>>     would need to be removed manually and may accidentally be
>> >>>     distributed.
>> >>>
>> >>> 4.  it is currently very difficult to roll version numbers forward,
>> >>>     entries here and there are often missed.  Far better to have
>> >>>     branches/x.y have a few straggling old x.y.z-SNAPSHOT versions
>> >>>     than a few overlooked x.y.z final numbers that needed to go back
>> >>>     to SNAPSHOT -- they never leave SNAPSHOT and need to be reverted
>> >>>     back later if that process happens in the frozen branch.
>> >>>
>> >>>
>> >>> Here is my +1
>> >>>
>> >>>
>> >>> -- David
>> >>>
>> >>>
>> >>>
>> >>> On Jun 21, 2006, at 4:14 PM, Matt Hogstrom wrote:
>> >>>
>> >>>> After the branches/1.1 was moved to tags there was some question
>> >>>> as to what happened to the 1.1 branch.  At that time some kind
>> >>>> soul created a new branches/1.1.1.  No activity has occurred in
>> >>>> that branch and given that we'll need to define the release
>> >>>> goals of 1.1.1 soon I'd like to propose the following.
>> >>>>
>> >>>> After 1.1 is released:
>> >>>>
>> >>>> * Delete branches/1.1.1
>> >>>> * Move branches/1.1.0 to tags/1.1.0
>> >>>> * Copy tags/1.1.0 to branches/1.1.1
>> >>>> * Update branches 1.1.1 to be 1.1.1-SNAPSHOT
>> >>>> * Start working on 1.1.1
>> >>>>
>> >>>> When 1.1.1 enters time for release
>> >>>>
>> >>>> * Move branches/1.1.1 to branches/1.1.1.0
>> >>>> * Change version from 1.1.1-SNAPSHOT to 1.1.1
>> >>>> * Create release candidate rc1
>> >>>> * put out for a vote
>> >>>> * get a successful vote with no respins :)
>> >>>> * move from branches/1.1.1.0 to tags/1.1.1.0
>> >>>>
>> >>>> Based on all the confusion in the past I think this procedure
>> >>>> makes it clear what phase were in for the release as well as
>> >>>> avoids tagging and branching repeatedly.
>> >>>>
>> >>>> I'm looking for lazy consensus and not a formal vote.
>> >>>>
>> >>>> Matt
>> >>>>
>> >>>
>> >>
>> >
>>
>>
> 
> 
> 

Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)

[Aaron Mulder <am...@alumni.princeton.edu>]

+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 another release candidate turns out to be
necessary.

Thanks,
    Aaron

On 6/22/06, Jason Dillon <ja...@planet57.com> wrote:
> 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 the point of the freeze the release manager owns the
> > branches/x.y.z till the vote passes.  That's the ideal scenario
> > anyway.
> >
> > -David
> >
> > On Jun 21, 2006, at 9:40 PM, 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 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 branch for all x.y.z releases
> >>>
> >>> 2.   when a release is frozen, we spin off a branch with that
> >>> *exact*
> >>>      name, as in branches/x.y.z, where z starts at zero and
> >>> increments
> >>>      by one.
> >>>
> >>> 3.   at that time branches/x.y is immediately updated to version
> >>>      x.y.(z+1)-SNAPSHOT
> >>>
> >>> 3.   We cut releases from the frozen branch
> >>>
> >>> 4.   When a release passes final tck testing and final vote, the
> >>>      frozen branch is moved to tags
> >>>
> >>> We create a branch at freeze time for the following reasons:
> >>>
> >>> 1.  it takes *at least* one week from freeze to ship due to voting,
> >>>     tck testing and potential repeats of that process (re-cut,
> >>>     re-certify, re-vote).  There is no reason why work on x.y.z+1
> >>>     needs to be delayed -- only 52 weeks a year.
> >>>
> >>> 2.  stronger guarantee no one is updating the branch once frozen
> >>>
> >>> 3.  less likely that people and ci systems (continuum) will checkout
> >>>     and build pre-release versions of x.y.z (not x.y.z-SNAPSHOT)
> >>> which
> >>>     would need to be removed manually and may accidentally be
> >>>     distributed.
> >>>
> >>> 4.  it is currently very difficult to roll version numbers forward,
> >>>     entries here and there are often missed.  Far better to have
> >>>     branches/x.y have a few straggling old x.y.z-SNAPSHOT versions
> >>>     than a few overlooked x.y.z final numbers that needed to go back
> >>>     to SNAPSHOT -- they never leave SNAPSHOT and need to be reverted
> >>>     back later if that process happens in the frozen branch.
> >>>
> >>>
> >>> Here is my +1
> >>>
> >>>
> >>> -- David
> >>>
> >>>
> >>>
> >>> On Jun 21, 2006, at 4:14 PM, Matt Hogstrom wrote:
> >>>
> >>>> After the branches/1.1 was moved to tags there was some question
> >>>> as to what happened to the 1.1 branch.  At that time some kind
> >>>> soul created a new branches/1.1.1.  No activity has occurred in
> >>>> that branch and given that we'll need to define the release
> >>>> goals of 1.1.1 soon I'd like to propose the following.
> >>>>
> >>>> After 1.1 is released:
> >>>>
> >>>> * Delete branches/1.1.1
> >>>> * Move branches/1.1.0 to tags/1.1.0
> >>>> * Copy tags/1.1.0 to branches/1.1.1
> >>>> * Update branches 1.1.1 to be 1.1.1-SNAPSHOT
> >>>> * Start working on 1.1.1
> >>>>
> >>>> When 1.1.1 enters time for release
> >>>>
> >>>> * Move branches/1.1.1 to branches/1.1.1.0
> >>>> * Change version from 1.1.1-SNAPSHOT to 1.1.1
> >>>> * Create release candidate rc1
> >>>> * put out for a vote
> >>>> * get a successful vote with no respins :)
> >>>> * move from branches/1.1.1.0 to tags/1.1.1.0
> >>>>
> >>>> Based on all the confusion in the past I think this procedure
> >>>> makes it clear what phase were in for the release as well as
> >>>> avoids tagging and branching repeatedly.
> >>>>
> >>>> I'm looking for lazy consensus and not a formal vote.
> >>>>
> >>>> Matt
> >>>>
> >>>
> >>
> >
>
>

Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)

[Jason Dillon <ja...@planet57.com>]

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 the point of the freeze the release manager owns the  
> branches/x.y.z till the vote passes.  That's the ideal scenario  
> anyway.
>
> -David
>
> On Jun 21, 2006, at 9:40 PM, 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 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 branch for all x.y.z releases
>>>
>>> 2.   when a release is frozen, we spin off a branch with that  
>>> *exact*
>>>      name, as in branches/x.y.z, where z starts at zero and  
>>> increments
>>>      by one.
>>>
>>> 3.   at that time branches/x.y is immediately updated to version
>>>      x.y.(z+1)-SNAPSHOT
>>>
>>> 3.   We cut releases from the frozen branch
>>>
>>> 4.   When a release passes final tck testing and final vote, the
>>>      frozen branch is moved to tags
>>>
>>> We create a branch at freeze time for the following reasons:
>>>
>>> 1.  it takes *at least* one week from freeze to ship due to voting,
>>>     tck testing and potential repeats of that process (re-cut,
>>>     re-certify, re-vote).  There is no reason why work on x.y.z+1
>>>     needs to be delayed -- only 52 weeks a year.
>>>
>>> 2.  stronger guarantee no one is updating the branch once frozen
>>>
>>> 3.  less likely that people and ci systems (continuum) will checkout
>>>     and build pre-release versions of x.y.z (not x.y.z-SNAPSHOT)  
>>> which
>>>     would need to be removed manually and may accidentally be
>>>     distributed.
>>>
>>> 4.  it is currently very difficult to roll version numbers forward,
>>>     entries here and there are often missed.  Far better to have
>>>     branches/x.y have a few straggling old x.y.z-SNAPSHOT versions
>>>     than a few overlooked x.y.z final numbers that needed to go back
>>>     to SNAPSHOT -- they never leave SNAPSHOT and need to be reverted
>>>     back later if that process happens in the frozen branch.
>>>
>>>
>>> Here is my +1
>>>
>>>
>>> -- David
>>>
>>>
>>>
>>> On Jun 21, 2006, at 4:14 PM, Matt Hogstrom wrote:
>>>
>>>> After the branches/1.1 was moved to tags there was some question  
>>>> as to what happened to the 1.1 branch.  At that time some kind  
>>>> soul created a new branches/1.1.1.  No activity has occurred in  
>>>> that branch and given that we'll need to define the release  
>>>> goals of 1.1.1 soon I'd like to propose the following.
>>>>
>>>> After 1.1 is released:
>>>>
>>>> * Delete branches/1.1.1
>>>> * Move branches/1.1.0 to tags/1.1.0
>>>> * Copy tags/1.1.0 to branches/1.1.1
>>>> * Update branches 1.1.1 to be 1.1.1-SNAPSHOT
>>>> * Start working on 1.1.1
>>>>
>>>> When 1.1.1 enters time for release
>>>>
>>>> * Move branches/1.1.1 to branches/1.1.1.0
>>>> * Change version from 1.1.1-SNAPSHOT to 1.1.1
>>>> * Create release candidate rc1
>>>> * put out for a vote
>>>> * get a successful vote with no respins :)
>>>> * move from branches/1.1.1.0 to tags/1.1.1.0
>>>>
>>>> Based on all the confusion in the past I think this procedure  
>>>> makes it clear what phase were in for the release as well as  
>>>> avoids tagging and branching repeatedly.
>>>>
>>>> I'm looking for lazy consensus and not a formal vote.
>>>>
>>>> Matt
>>>>
>>>
>>
>

Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)

[David Blevins <da...@visi.com>]

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 vote passes.  That's the ideal scenario anyway.

-David

On Jun 21, 2006, at 9:40 PM, 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 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 branch for all x.y.z releases
>>
>> 2.   when a release is frozen, we spin off a branch with that *exact*
>>      name, as in branches/x.y.z, where z starts at zero and  
>> increments
>>      by one.
>>
>> 3.   at that time branches/x.y is immediately updated to version
>>      x.y.(z+1)-SNAPSHOT
>>
>> 3.   We cut releases from the frozen branch
>>
>> 4.   When a release passes final tck testing and final vote, the
>>      frozen branch is moved to tags
>>
>> We create a branch at freeze time for the following reasons:
>>
>> 1.  it takes *at least* one week from freeze to ship due to voting,
>>     tck testing and potential repeats of that process (re-cut,
>>     re-certify, re-vote).  There is no reason why work on x.y.z+1
>>     needs to be delayed -- only 52 weeks a year.
>>
>> 2.  stronger guarantee no one is updating the branch once frozen
>>
>> 3.  less likely that people and ci systems (continuum) will checkout
>>     and build pre-release versions of x.y.z (not x.y.z-SNAPSHOT)  
>> which
>>     would need to be removed manually and may accidentally be
>>     distributed.
>>
>> 4.  it is currently very difficult to roll version numbers forward,
>>     entries here and there are often missed.  Far better to have
>>     branches/x.y have a few straggling old x.y.z-SNAPSHOT versions
>>     than a few overlooked x.y.z final numbers that needed to go back
>>     to SNAPSHOT -- they never leave SNAPSHOT and need to be reverted
>>     back later if that process happens in the frozen branch.
>>
>>
>> Here is my +1
>>
>>
>> -- David
>>
>>
>>
>> On Jun 21, 2006, at 4:14 PM, Matt Hogstrom wrote:
>>
>>> After the branches/1.1 was moved to tags there was some question  
>>> as to what happened to the 1.1 branch.  At that time some kind  
>>> soul created a new branches/1.1.1.  No activity has occurred in  
>>> that branch and given that we'll need to define the release goals  
>>> of 1.1.1 soon I'd like to propose the following.
>>>
>>> After 1.1 is released:
>>>
>>> * Delete branches/1.1.1
>>> * Move branches/1.1.0 to tags/1.1.0
>>> * Copy tags/1.1.0 to branches/1.1.1
>>> * Update branches 1.1.1 to be 1.1.1-SNAPSHOT
>>> * Start working on 1.1.1
>>>
>>> When 1.1.1 enters time for release
>>>
>>> * Move branches/1.1.1 to branches/1.1.1.0
>>> * Change version from 1.1.1-SNAPSHOT to 1.1.1
>>> * Create release candidate rc1
>>> * put out for a vote
>>> * get a successful vote with no respins :)
>>> * move from branches/1.1.1.0 to tags/1.1.1.0
>>>
>>> Based on all the confusion in the past I think this procedure  
>>> makes it clear what phase were in for the release as well as  
>>> avoids tagging and branching repeatedly.
>>>
>>> I'm looking for lazy consensus and not a formal vote.
>>>
>>> Matt
>>>
>>
>

Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)

[Jason Dillon <ja...@planet57.com>]

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 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 branch for all x.y.z releases
>
> 2.   when a release is frozen, we spin off a branch with that *exact*
>      name, as in branches/x.y.z, where z starts at zero and increments
>      by one.
>
> 3.   at that time branches/x.y is immediately updated to version
>      x.y.(z+1)-SNAPSHOT
>
> 3.   We cut releases from the frozen branch
>
> 4.   When a release passes final tck testing and final vote, the
>      frozen branch is moved to tags
>
> We create a branch at freeze time for the following reasons:
>
> 1.  it takes *at least* one week from freeze to ship due to voting,
>     tck testing and potential repeats of that process (re-cut,
>     re-certify, re-vote).  There is no reason why work on x.y.z+1
>     needs to be delayed -- only 52 weeks a year.
>
> 2.  stronger guarantee no one is updating the branch once frozen
>
> 3.  less likely that people and ci systems (continuum) will checkout
>     and build pre-release versions of x.y.z (not x.y.z-SNAPSHOT) which
>     would need to be removed manually and may accidentally be
>     distributed.
>
> 4.  it is currently very difficult to roll version numbers forward,
>     entries here and there are often missed.  Far better to have
>     branches/x.y have a few straggling old x.y.z-SNAPSHOT versions
>     than a few overlooked x.y.z final numbers that needed to go back
>     to SNAPSHOT -- they never leave SNAPSHOT and need to be reverted
>     back later if that process happens in the frozen branch.
>
>
> Here is my +1
>
>
> -- David
>
>
>
> On Jun 21, 2006, at 4:14 PM, Matt Hogstrom wrote:
>
>> After the branches/1.1 was moved to tags there was some question  
>> as to what happened to the 1.1 branch.  At that time some kind  
>> soul created a new branches/1.1.1.  No activity has occurred in  
>> that branch and given that we'll need to define the release goals  
>> of 1.1.1 soon I'd like to propose the following.
>>
>> After 1.1 is released:
>>
>> * Delete branches/1.1.1
>> * Move branches/1.1.0 to tags/1.1.0
>> * Copy tags/1.1.0 to branches/1.1.1
>> * Update branches 1.1.1 to be 1.1.1-SNAPSHOT
>> * Start working on 1.1.1
>>
>> When 1.1.1 enters time for release
>>
>> * Move branches/1.1.1 to branches/1.1.1.0
>> * Change version from 1.1.1-SNAPSHOT to 1.1.1
>> * Create release candidate rc1
>> * put out for a vote
>> * get a successful vote with no respins :)
>> * move from branches/1.1.1.0 to tags/1.1.1.0
>>
>> Based on all the confusion in the past I think this procedure  
>> makes it clear what phase were in for the release as well as  
>> avoids tagging and branching repeatedly.
>>
>> I'm looking for lazy consensus and not a formal vote.
>>
>> Matt
>>
>

[VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)

[David Blevins <da...@visi.com>]

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 branch for all x.y.z releases

2.   when a release is frozen, we spin off a branch with that *exact*
      name, as in branches/x.y.z, where z starts at zero and increments
      by one.

3.   at that time branches/x.y is immediately updated to version
      x.y.(z+1)-SNAPSHOT

3.   We cut releases from the frozen branch

4.   When a release passes final tck testing and final vote, the
      frozen branch is moved to tags

We create a branch at freeze time for the following reasons:

1.  it takes *at least* one week from freeze to ship due to voting,
     tck testing and potential repeats of that process (re-cut,
     re-certify, re-vote).  There is no reason why work on x.y.z+1
     needs to be delayed -- only 52 weeks a year.

2.  stronger guarantee no one is updating the branch once frozen

3.  less likely that people and ci systems (continuum) will checkout
     and build pre-release versions of x.y.z (not x.y.z-SNAPSHOT) which
     would need to be removed manually and may accidentally be
     distributed.

4.  it is currently very difficult to roll version numbers forward,
     entries here and there are often missed.  Far better to have
     branches/x.y have a few straggling old x.y.z-SNAPSHOT versions
     than a few overlooked x.y.z final numbers that needed to go back
     to SNAPSHOT -- they never leave SNAPSHOT and need to be reverted
     back later if that process happens in the frozen branch.


Here is my +1


--  
David



On Jun 21, 2006, at 4:14 PM, Matt Hogstrom wrote:

> After the branches/1.1 was moved to tags there was some question as  
> to what happened to the 1.1 branch.  At that time some kind soul  
> created a new branches/1.1.1.  No activity has occurred in that  
> branch and given that we'll need to define the release goals of  
> 1.1.1 soon I'd like to propose the following.
>
> After 1.1 is released:
>
> * Delete branches/1.1.1
> * Move branches/1.1.0 to tags/1.1.0
> * Copy tags/1.1.0 to branches/1.1.1
> * Update branches 1.1.1 to be 1.1.1-SNAPSHOT
> * Start working on 1.1.1
>
> When 1.1.1 enters time for release
>
> * Move branches/1.1.1 to branches/1.1.1.0
> * Change version from 1.1.1-SNAPSHOT to 1.1.1
> * Create release candidate rc1
> * put out for a vote
> * get a successful vote with no respins :)
> * move from branches/1.1.1.0 to tags/1.1.1.0
>
> Based on all the confusion in the past I think this procedure makes  
> it clear what phase were in for the release as well as avoids  
> tagging and branching repeatedly.
>
> I'm looking for lazy consensus and not a formal vote.
>
> Matt
>

Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.

["Alan D. Cabrera" <li...@toolazydogs.com>]

Matt Hogstrom wrote:
> After the branches/1.1 was moved to tags there was some question as to 
> what happened to the 1.1 branch.  At that time some kind soul created 
> a new branches/1.1.1.  No activity has occurred in that branch and 
> given that we'll need to define the release goals of 1.1.1 soon I'd 
> like to propose the following.
>
> After 1.1 is released:
>
> * Delete branches/1.1.1
> * Move branches/1.1.0 to tags/1.1.0
> * Copy tags/1.1.0 to branches/1.1.1
> * Update branches 1.1.1 to be 1.1.1-SNAPSHOT
> * Start working on 1.1.1
>
> When 1.1.1 enters time for release
>
> * Move branches/1.1.1 to branches/1.1.1.0
> * Change version from 1.1.1-SNAPSHOT to 1.1.1
> * Create release candidate rc1
> * put out for a vote
> * get a successful vote with no respins :)
> * move from branches/1.1.1.0 to tags/1.1.1.0
>
> Based on all the confusion in the past I think this procedure makes it 
> clear what phase were in for the release as well as avoids tagging and 
> branching repeatedly.
>
> I'm looking for lazy consensus and not a formal vote.
>
> Matt
The whole point in having a 1.1.1 branch was to busily put in patches 
while 1.1.0 goes out the door.  Since nothing was done on that branch, I 
don't see why we don't use branches/1.1 as the "trunk" for 1.1.x patches.


Regards,
Alan