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/23 21:30:09 UTC
[VOTE] move current release to 1.0.0-SNAPSHOT
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
Re: [VOTE] move current release to 1.0.0-SNAPSHOT
Posted by Marc Prud'hommeaux <mp...@apache.org>.
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 <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
>
RE: [VOTE] move current release to 1.0.0-SNAPSHOT
Posted by Phill Moran <pj...@rogers.com>.
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 <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
[VOTE RESULT] move current release to 1.0.0-SNAPSHOT
Posted by Marc Prud'hommeaux <mp...@apache.org>.
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!
>
Re: [VOTE] move current release to 1.0.0-SNAPSHOT
Posted by Craig L Russell <Cr...@Sun.COM>.
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!
Re: [VOTE] move current release to 1.0.0-SNAPSHOT
Posted by Patrick Linskey <pl...@gmail.com>.
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 <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
Re: [VOTE] move current release to 1.0.0-SNAPSHOT
Posted by Craig L Russell <Cr...@Sun.COM>.
-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!
Re: [VOTE] move current release to 1.0.0-SNAPSHOT
Posted by Kevin Sutter <kw...@gmail.com>.
+1 for the 1.0.0-SNAPSHOT
On 5/23/07, Marc Prud'hommeaux <mp...@apache.org> 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
>
>
>
RE: [VOTE] move current release to 1.0.0-SNAPSHOT
Posted by Phill Moran <pj...@rogers.com>.
+1
There are Jira entries and there always will be. I think we are ready
-----Original Message-----
From: Marc Prud'hommeaux [mailto:mprudhomapache@gmail.com] On Behalf Of Marc
Prud'hommeaux
Sent: May 23, 2007 3:30 PM
To: open-jpa-dev@incubator.apache.org
Subject: [VOTE] move current release to 1.0.0-SNAPSHOT
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