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: [REMINDER] 1.0.0 branch tonight
Date Thu, 23 Aug 2007 00:30:17 GMT

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 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 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 <michael.d.dick@gmail.com> wrote:
>> On 8/20/07, Marc Prud'hommeaux <mprudhom@apache.org> 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 <mprudhom@apache.org> 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 <mprudhom@apache.org> 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

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