You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by Marc Prud'hommeaux <mp...@apache.org> on 2007/05/26 21:18:11 UTC

[VOTE RESULT] move current release to 1.0.0-SNAPSHOT

With 5 votes in favor and 0 against, the vote passes.

I've gone ahead and updated the pom.xml files to set the version to  
be "1.0.0-SNAPSHOT" and changed the wiki downloads page that points  
to the snapshot release.

Thank you all for voting!



On May 24, 2007, at 11:16 AM, Craig L Russell wrote:

> Changing my vote to +1 after this discussion.
>
> I agree this is the right discussion to have.
>
> On May 23, 2007, at 5:41 PM, Patrick Linskey wrote:
>
>> How do 1.0 and 1.0.0 differ? The way I've done things in the past,  
>> the
>> first major release is called 1.0.0, the first patch release 1.0.1,
>> etc.
>
> The way I've done things is the first major release is called 1.0,  
> the first patch release is 1.0.1, etc. So we're not too far off.
>
>> Then, when I say "1.0", what I really mean is "the latest code in
>> the 1.0 branch, whatever that is right now".
>
> That's a new one on me. But I can see it has merit.
>>
>> When we did Kodo releases in the past, we tried hard to not do new
>> feature development in a maintenance branch.
>
> Right.
>
>> So, following that
>> methodology, once we released 1.0.0, we would make a 1.0 branch,  
>> which
>> would periodically have tags on it when we release 1.0.1 etc. As soon
>> as 1.0 was out, all the interesting new cool stuff would then go into
>> the mainline, which would be 1.1.0-SNAPSHOT. (Unless, of course, we
>> had already cut a branch for 1.1 also, in which case the mainline
>> would be 1.2.0-SNAPSHOT, etc.)
>
> Ok. I can see that this naming scheme is consistent. And I think we  
> can use this along with Phill's suggestions:
>
>> Why don't we follow (I believe the SUN standard)  convention of  
>> using the three
>> digits as in 1.2.3.
>> A change from 1.2.3 to 1.2.4 is a bug fix release no new  
>> functionality and fully
>> backward compatible.
>
> Backward compatible == user classes built with e.g. 1.1.4 will  
> execute with 1.1.5 but user classes built with 1.1.5 won't  
> necessarily work with 1.1.4.
>
>> A change from 1.2.3 to 1.3 can have new functionality and bug  
>> fixes but is fully
>> backwards compatible.
>
> New features can be added but only in a backward compatible way.
>
>> Finally a change from 1.2.3 to 2.0 is new functionality, bug fixes  
>> and no
>> guarantee of backward compatibility
>
> Backward compatibility is still a goal but not a requirement.
>
> Craig
>
>>
>> -Patrick
>>
>> On 5/23/07, Craig L Russell <Cr...@sun.com> wrote:
>>> -1
>>>
>>> I like the idea of having our first release out of the incubator  
>>> be 1.0.
>>>
>>> Let's drop the trailing .0 and reserve the third digit for patch
>>> releases. This brings up the issue of release naming which we've
>>> deferred until now. I think we need to decide what we call releases
>>> and at what level we support backward compatibility.
>>>
>>> I'll just emphasize my earlier comments about going through the open
>>> JIRA issues and really making sure that we'll address the major
>>> functionality, performance, and usability deficiencies. So this will
>>> affect the schedule but not the naming of the release.
>>>
>>> Craig
>>>
>>> On May 23, 2007, at 12:30 PM, Marc Prud'hommeaux wrote:
>>>
>>> >
>>> > We recently discussed committing ourselves to the next release
>>> > being OpenJPA 1.0.0. The general consensus seems to be in  
>>> favor, so
>>> > I'm putting it to a vote.
>>> >
>>> >  +1 Make the current release be 1.0.0-SNAPSHOT, which indicates
>>> > that the next released version will be 1.0.0
>>> >  -1 Leave the current release to be 0.9.8-SNAPSHOT
>>> >  0 Don't care
>>> >
>>> > This vote will remain open until 12pm PST on 5/26.
>>> >
>>> > I'll start the voting off by recording my vote: +1
>>> >
>>> >
>>>
>>> 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!
>>>
>>>
>>>
>>
>>
>> -- 
>> 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!
>