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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]
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:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
