> Maybe I wasn't clear in what I meant when I replied last night. I'm all for > the 1.0.0 branch, I'm ambivalent about needing a 1.1.0 branch in addition to > the 1.0.0 branch. I think that trunk can be used for all new function until
Agreed (almost). I agree that we should be doing 1.1-related work in the trunk, at least for now. The 1.0.0 branch that Marc created is a special-purpose, release-transient thing. We won't cut a 1.0.1 release from the 1.0.0 branch. I'm suggesting that we create a 1.0 branch (note the lack of the trailing patch number) that all the 1.0.x work will be isolated to. I think that we're talking about the same stuff, just with different terms. -Patrick On 8/21/07, Michael Dick <[EMAIL PROTECTED]> wrote: > I think I agree with most of what you said - I just didn't explain myself > well last night. Creating the 1.0.0 branch right away is the right thing to > do, and it's one of the things that I messed up on with release 0.9.7. > > Maybe I wasn't clear in what I meant when I replied last night. I'm all for > the 1.0.0 branch, I'm ambivalent about needing a 1.1.0 branch in addition to > the 1.0.0 branch. I think that trunk can be used for all new function until > we need a branch (ie release 1.1) or add function that requires a major > version update (2.0). > > -Mike > > On 8/21/07, Patrick Linskey <[EMAIL PROTECTED]> wrote: > > > > > The plan can change when we have a roadmap in place or have targetted > > JIRA > > > issues 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 > > a > > > bit. 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 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. 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. > > > > 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 and > > > > then re-cut the release without worrying about other changes that may > > > > have been slipped into the trunk. > > > > > > > > > > > > Whether or not we have a parent "1.0" branch to the "1.0.0" branch is > > > > not 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 make > > > > sense 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 making > > > > a "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 > > JIRA > > > issues 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 > > a > > > bit. 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 > > future > > > > > work in the 1.0 line will happen in it. So, if something goes wrong > > > > > while 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 > > on > > > > > trunk, 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 > > yet > > > > >> to 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 > > > > >>> tag > > > > >>> off of it, so that we have somewhere to work on 1.0.1. Or do > > things > > > > >>> work 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 release > > > > >>>> candidate will be immediately created for voting on the final > > 1.0.0 > > > > >>>> release. > > > > >>>> > > > > >>>> 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 > > > -- Patrick Linskey 202 669 5907
