openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Albert Lee" <allee8...@gmail.com>
Subject Re: OpenJPA Release Policy
Date Tue, 05 Feb 2008 02:45:49 GMT
> We have x.y.z numbering. It's not clear what your n and n+1 refer to
> above. The policy as I've tried to summarize as the consensus is that
> major releases have no guarantee of compatibility, as methods might be
> removed or signatures changed to follow specification updates or to
> add new features. Minor releases and patch releases do guarantee
> compatibility.

Apology for the unclear comment. I understand no guarantee is made between
major releases due to your aforementioned reasons. I am referring to the
minor n/n+1 releases. E.g. 1.1.x and 1.2.x.

> Do you want to try to guarantee source and or binary compatibility, or
> just have it as a goal?

I am hoping for both binary and source compatibility.

Albert Lee.
On Feb 4, 2008 3:41 PM, Craig L Russell <Craig.Russell@sun.com> wrote:

> Hi Albert,
>
> Thanks for your comments.
>
> On Feb 2, 2008, at 8:22 PM, Albert Lee wrote:
>
> > * Major release - Should the major release parallels to the JPA spec
> > numbering?
>
> Well, I think we should bump the major release number to correspond to
> JPA spec number where it makes sense. But we don't control JPA spec
> numbering. We might choose to make a 2.1.0 release some months or
> years after JPA 2.0 comes out, and then JPA is updated to a 2.1
> release. At that point, we're out of sync. (Note that Java EE 6
> proposes EJB 3.1 and JPA 2.0)
> >
> > * Backward compatibility - I just want clarifications on the following
> > scenario:
> >
> >  - application compiled in (n)th release can execute in (n+1)th
> > release
> > without re-compilation.
> >  - application, with no source change, re-compiles in (n+1)th
> > release can
> > execute in (n)th release.
> >  - application, with source change that use new functions, re-
> > compiles in
> > (n+1)th release can only be executed in (n+1)th release.
>
> We have x.y.z numbering. It's not clear what your n and n+1 refer to
> above. The policy as I've tried to summarize as the consensus is that
> major releases have no guarantee of compatibility, as methods might be
> removed or signatures changed to follow specification updates or to
> add new features. Minor releases and patch releases do guarantee
> compatibility.
>
> Do you want to try to guarantee source and or binary compatibility, or
> just have it as a goal?
>
> Craig
> >
> >
> > Thanks,
> > Albert Lee.
> >
> > On Feb 2, 2008 5:40 PM, Craig L Russell <Craig.Russell@sun.com> wrote:
> >
> >> Hi,
> >>
> >> I'd like to formalize our release policy. Please take a look at
> >> http://cwiki.apache.org/confluence/pages/viewpage.action?pageId=55076
> >> and comment.
> >>
> >> I'd like to remove the *DRAFT* status of the policy next week.
> >>
> >> Craig
> >>
> >> 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!
> >>
> >>
> >
> >
> > --
> > Albert Lee.
>
> 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!
>
>


-- 
Albert Lee.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message