You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by Craig L Russell <Cr...@Sun.COM> on 2008/02/03 00:40:24 UTC
OpenJPA Release Policy
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!
Re: OpenJPA Release Policy
Posted by Albert Lee <al...@gmail.com>.
> 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 <Cr...@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 <Cr...@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.
Re: OpenJPA Release Policy
Posted by Craig L Russell <Cr...@Sun.COM>.
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 <Cr...@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!
Re: OpenJPA Release Policy
Posted by Michael Dick <mi...@apache.org>.
On Feb 4, 2008 1:45 PM, Patrick Linskey <pl...@gmail.com> wrote:
> > * Major release - Should the major release parallels to the JPA spec
> > numbering?
>
> I don't think so. For JPA2, it's convenient to do so. But I don't
> think that that will always be the case.
>
+1
>
> > - application, with no source change, re-compiles in (n+1)th release
> can
> > execute in (n)th release.
>
> Just to clarify, you mean "application that executed in (n)th release
> can re-compile in (n+1)th release", right?
>
> -Patrick
>
> On Feb 2, 2008 8:22 PM, Albert Lee <al...@gmail.com> wrote:
> > * Major release - Should the major release parallels to the JPA spec
> > numbering?
> >
> > * 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.
> >
> > Thanks,
> > Albert Lee.
> >
> >
> > On Feb 2, 2008 5:40 PM, Craig L Russell <Cr...@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.
> >
>
>
>
> --
> Patrick Linskey
> 202 669 5907
>
Re: OpenJPA Release Policy
Posted by Albert Lee <al...@gmail.com>.
> * Major release
> - I don't think so. For JPA2, it's convenient to do so. But I don't
> think that that will always be the case.
Agree.
>> - application, with no source change, re-compiles in (n+1)th release can
>> execute in (n)th release.
> Just to clarify, you mean "application that executed in (n)th release
> can re-compile in (n+1)th release", right?
What I am trying to state is if the source in (n)th release compile and run
and it has not changed, i.e. not using any new functions in (n+1), I should
be able to recompile under the (n+1)th environment and take it back to the
(n)th and run successfully. So it is binary backward compatible only if no
new functions is used.
Albert Lee.
On Feb 4, 2008 1:45 PM, Patrick Linskey <pl...@gmail.com> wrote:
> > * Major release - Should the major release parallels to the JPA spec
> > numbering?
>
> I don't think so. For JPA2, it's convenient to do so. But I don't
> think that that will always be the case.
>
> > - application, with no source change, re-compiles in (n+1)th release
> can
> > execute in (n)th release.
>
> Just to clarify, you mean "application that executed in (n)th release
> can re-compile in (n+1)th release", right?
>
> -Patrick
>
> On Feb 2, 2008 8:22 PM, Albert Lee <al...@gmail.com> wrote:
> > * Major release - Should the major release parallels to the JPA spec
> > numbering?
> >
> > * 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.
> >
> > Thanks,
> > Albert Lee.
> >
> >
> > On Feb 2, 2008 5:40 PM, Craig L Russell <Cr...@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.
> >
>
>
>
> --
> Patrick Linskey
> 202 669 5907
>
--
Albert Lee.
Re: OpenJPA Release Policy
Posted by Patrick Linskey <pl...@gmail.com>.
> * Major release - Should the major release parallels to the JPA spec
> numbering?
I don't think so. For JPA2, it's convenient to do so. But I don't
think that that will always be the case.
> - application, with no source change, re-compiles in (n+1)th release can
> execute in (n)th release.
Just to clarify, you mean "application that executed in (n)th release
can re-compile in (n+1)th release", right?
-Patrick
On Feb 2, 2008 8:22 PM, Albert Lee <al...@gmail.com> wrote:
> * Major release - Should the major release parallels to the JPA spec
> numbering?
>
> * 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.
>
> Thanks,
> Albert Lee.
>
>
> On Feb 2, 2008 5:40 PM, Craig L Russell <Cr...@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.
>
--
Patrick Linskey
202 669 5907
Re: OpenJPA Release Policy
Posted by Albert Lee <al...@gmail.com>.
* Major release - Should the major release parallels to the JPA spec
numbering?
* 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.
Thanks,
Albert Lee.
On Feb 2, 2008 5:40 PM, Craig L Russell <Cr...@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.