On Aug 21, 2007, at 8:31 AM, Patrick Linskey wrote:
The plan can change when we have a roadmap in place or have targetted JIRAissues for 1.1 vs 2.0.0.While creating the 1.0 parent branch is probably cleaner schematically I don't see a practical benefit unless there are changes coming that warrant a major release. Until we get to that point I'm content to play it by ear abit. That's just MHO though.So in my opinion, both major and minor releases deserve to be on their own branches. In my experience, major and minor lines can be treated as equivalent from a SCM standpoint.
I agree. I don't see the need for basing 1.1.0 on 1.0.0. But the continuation of 1.0.0 to 1.0.1, 1.0.2, etc should be on the 1.0.0 branch.
At some point we might want to start putting some major unstable features into the code and make a branch for that work. But I think we're pretty far from that point.
I believe that we should branch immediately because I think that it is useful to limit the work in the 1.0.x line to bugfixes.
Yes.
For example, I just committed a patch (a couple hours late) for OPENJPA-256. That patch can trivially be part of 1.0.1, but other new work that we do for other projects (for example, Ignacio's streaming-lob project) seems like it's higher-impact, and therefore should go into the 1.1 line.
Which we can work on in the trunk. Craig
I agree that this means more thinking on our part, in order to work out where to put a given code change and in terms of periodic merging, but I think that it's worth the cost. Otherwise, we essentially get into a mode where we cannot do patch releases with any guarantees for existing users. I think that probably a decent compromise policy is to branch immediately, and then for people to do all work in trunk unless they feel the urge to do otherwise. We could decide that we won't do bulk merges from maintenance branches back to the trunk, so if people want to create bugfix releases, they'll have to do the work to merge patches from trunk to the branch on their own. In that environment, we'd have an ad-hoc means to support patch releases without mandating any additional work for OpenJPA contributors who are happy to consume the trunk contents. -Patrick On 8/20/07, Michael Dick <[EMAIL PROTECTED]> wrote:On 8/20/07, Marc Prud'hommeaux <[EMAIL PROTECTED]> wrote:We will create a "1.0.0" branch as per the existing release process at http://openjpa.apache.org/releasing-openjpa.html , so that if anyone objects to the release for technical reasons (e.g., misplaces license file), we can make those repairs in the "1.0.0" branch andthen re-cut the release without worrying about other changes that mayhave been slipped into the trunk.Whether or not we have a parent "1.0" branch to the "1.0.0" branch isnot something I have considered. Does anyone have any thoughts about this? If so, we'll need to make it clear to people what work should go into the "1.0" branch and what work should go into the trunk. Since we don't have much of a long-term roadmap yet, it might makesense to wait until we know which major features will go into OpenJPA 1.1, 2.0, 3.0, etc. However, I don't have strong objections to makinga "1.0" branch. Thoughts?I'd prefer to wait until we have a roadmap in place. If we create a parent branch then we'll end up doing a lot of dual maintenance with trunk and 1.0. If/when we need to add new function which breaks backwards compatibility then we can create a branch for 1.x and go forward with 2.0.0 in trunk.The plan can change when we have a roadmap in place or have targetted JIRAissues for 1.1 vs 2.0.0.While creating the 1.0 parent branch is probably cleaner schematically I don't see a practical benefit unless there are changes coming that warrant a major release. Until we get to that point I'm content to play it by ear abit. That's just MHO though. -Mike On Aug 20, 2007, at 6:20 PM, Patrick Linskey wrote:Well, I definitely don't think that work should happen in a branch called 1.0.0. Rather, it would seem that we would want to create a branch called 1.0, and tag from it.I think that we should make a 1.0 branch tonight, and then all futurework in the 1.0 line will happen in it. So, if something goes wrongwhile building / voting on the release, we'll resolve those issues in the 1.0 branch, not in trunk. That way, people can keep on working ontrunk, which will immediately become the 1.1 train. -Patrick On 8/20/07, Marc Prud'hommeaux <[EMAIL PROTECTED]> wrote:Patrick-I expect that we'll keep the "1.0.0" branch around, and then make a"1.0.0" tag once the release is cut and approved.What happens with the "1.0.0" branch (i.e., if 1.0.1 work takes place in the 1.0.0 branch or in trunk) is, I believe, a topic that has yetto be discussed. On Aug 20, 2007, at 1:42 PM, Patrick Linskey wrote:Hi, I think that we should be making a permanent 1.0 branch, and then tagoff of it, so that we have somewhere to work on 1.0.1. Or do thingswork differently in svn? -Patrick On 8/20/07, Marc Prud'hommeaux <[EMAIL PROTECTED]> wrote:OpenJPA Developers- Pursuant to the vote at http://www.nabble.com/-DISCUSS--set-a- deadline-for-1.0.0-features-t4233167.html , a branch for OpenJPA 1.0.0 will be created tonight at 11:59 PM EST, and a releasecandidate will be immediately created for voting on the final 1.0.0release. If anyone needs more time for essential bugfixes, now is the time to speak up. -- Marc Prud'hommeaux-- Patrick Linskey 202 669 5907-- Patrick Linskey 202 669 5907-- Patrick Linskey 202 669 5907
Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
