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