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: [VOTE] move current release to 1.0.0-SNAPSHOT
Date Thu, 24 May 2007 18:16:05 GMT
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 <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

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