Re: [VOTE] move current release to 1.0.0-SNAPSHOT

[Craig L Russell]

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.

backward compatible.

A change from 1.2.3 to 1.2.4 is a bug fix release no new functionality and fully

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



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

I like the idea of having our first release out of the incubator be 1.0. 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!

smime.p7s
Description: S/MIME cryptographic signature