openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Prud'hommeaux <mprud...@apache.org>
Subject Re: [VOTE] move current release to 1.0.0-SNAPSHOT
Date Thu, 24 May 2007 03:37:35 GMT

I personally like the "x.y.z" convention as well, as it provides more  
flexibility for small maintenance/bug-fix releases. A casual quick  
scan through various jakarta projects seems to show about an even  
split between projects that use "x.y.z" and "x.y" conventions.

Craig: is your objection merely a "x.y.z" vs. "x.y" convention? I.e.,  
do you agree with the spirit of the vote, which is that the next  
release will be "1", regardless of whether we call it "1", "1.0",  
"1.0.0", or "1.0.0.0"? And when you say "Let's drop the trailing .0  
and reserve the third digit for patch releases", do you mean that you  
would like to see an initial release be "1.0", and if there is a  
small patch release after that, it would be "1.0.1"? Or are you  
saying that you would prefer all releases to be of the "x.y" format?



On May 23, 2007, at 8:25 PM, Phill Moran wrote:

> 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.
> A change from 1.2.3 to 1.3 can have new functionality and bug fixes  
> but is fully
> backwards compatible.
> Finally a change from 1.2.3 to 2.0 is new functionality, bug fixes  
> and no
> guarantee of backward compatibility
>
> -----Original Message-----
> From: Patrick Linskey [mailto:plinskey@gmail.com]
> Sent: May 23, 2007 8:41 PM
> To: open-jpa-dev@incubator.apache.org
> Subject: Re: [VOTE] move current release to 1.0.0-SNAPSHOT
>
> 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.  
> Then, when I
> say "1.0", what I really mean is "the latest code in the 1.0  
> branch, whatever
> that is right now".
>
> When we did Kodo releases in the past, we tried hard to not do new  
> feature
> development in a maintenance branch. 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.)
>
> -Patrick
>
> On 5/23/07, Craig L Russell <Craig.Russell@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
>


Mime
View raw message