openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: svn commit: r569253 - in /openjpa/branches/1.0.0/openjpa-kernel/src/main: java/org/apache/openjpa/enhance/PCEnhancer.java resources/org/apache/openjpa/enhance/localizer.properties
Date Mon, 27 Aug 2007 22:08:25 GMT

On Aug 26, 2007, at 9:29 PM, Patrick Linskey wrote:

> In my opinion, I think we should let developers check things in
> wherever they want to.

I'm all for giving developers the freedom to scratch their itch, but  
I believe this goes too far. If I am a release manager, I really  
don't want to have to deal with a moving target. My idea of the role  
of RM is to dictate what goes in and what stays out.

> I think that most development work should
> happen in trunk unless we have a reason for it to happen elsewhere.

Sure, and I'd formalize it more. Development happens in the trunk  
unless the change you want to make doesn't belong in trunk. When does  
that happen? When you're patching released code that has been  
reorganized in the trunk so it doesn't apply any more.

> So, for example, if a developer has a fix that I think needs to be in
> a patch release, I think that it should be up to that developer to put
> the fix into the appropriate release branch.

This disempowers the RM. I'm much more comfortable with the RM  
deciding whether a patch is worth the potential destabilization of  
the release branch.

> We still haven't really
> discussed merging that much in that other thread; if we go with a
> model in which it is not the RM's responsibility to do a post-release
> merge to trunk, then we should require developers to put work into
> trunk as well as whatever release branch they deem fit, as
> appropriate.

There's already enough on the RM's plate to make a successful  
release. I'd rather not burden RM with the responsibility of post- 
release merge into the trunk that's already changed in the weeks  
since the branch was cut.
>
> (In the case of the 1.0.0 line, I've been committing things to it
> directly and not to trunk, on the assumption that we'll be doing a
> bulk merge from 1.0.0 to trunk once we're done with the release.)

Ok, bygones. "Someone" will need to merge these changes into trunk.  
But why wait? The thing I'm missing is that a patch is so important  
that it needs to go into the release branch immediately, but it's not  
important enough to go into the trunk immediately.

So here's my proposal, using the current state of play.

Trunk is versioned 1.1.0-SNAPSHOT. Branch/1.0 is versioned 1.0.1- 
SNAPSHOT. Tag/1.0.0 is versioned 1.0.0 and is frozen.

Developers commit changes to trunk, and if they feel like it, merge  
or hand copy the changes to branch/1.0. Any branch that is touched is  
tested to make sure the change doesn't break anything. Nothing goes  
into tag/1.0.0.

A release manager is volunteered to make 1.0.1. No one is allowed to  
commit to branch/1.0 without permission from RM. Branch/1.0 is  
versioned 1.0.1 by RM. Release notes are updated in branch/1.0.  
Testing occurs. Release candidates are produced. Votes are taken.  
Vote passes. Tag/1.0.1 is created from the living end of branch/1.0.  
Branch/1.0 is versioned 1.0.2-SNAPSHOT.

Repeat above until we decide to cut a 1.1. RM is volunteered. RM  
creates branch/1.1 from trunk. Branch/1.1 is versioned 1.1.0 by RM.  
Release notes, testing, release candidates, voting, success. Tag/ 
1.1.0 is created from the living end of branch/1.1. Branch/1.1 is  
versioned 1.1.1-SNAPSHOT.

Life goes on.



Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!


Mime
View raw message