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 >
