You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@openjpa.apache.org by Craig L Russell <Cr...@Sun.COM> on 2008/01/31 21:10:39 UTC
[DISCUSS] Release planning
It looks like we're closing in on a 1.0.2 release. There has been a
request for an official release that contains the streaming LOB
support, https://issues.apache.org/jira/browse/OPENJPA-130 that is not
yet completely documented and not ported to 1.0.2.
Are there other features in 1.1.0 that are urgently needed and that
can be pulled into 1.0.2?
I'd also like to start thinking about JPA 2.0 work. How should we
handle this? Seems that we would want to call the release that
supports JPA 2.0 OpenJPA 2.0. When we do start working on this, should
we use the trunk or a branch for it?
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: [DISCUSS] Release planning
Posted by Kevin Sutter <kw...@gmail.com>.
Patrick and Craig,
On Jan 31, 2008 8:04 PM, Patrick Linskey <pl...@gmail.com> wrote:
> > It looks like we're closing in on a 1.0.2 release.
>
> Indeed. I'm planning to go through the unscheduled bugs tomorrow to
> get a feeling for other issues that need to be in 1.0.2, and start the
> process of trying to get to 1.0.2 readiness over the next weeks.
FYI... We just discovered another change yesterday that needs to be ported
to 1.0.2. We're doing some final testing and verification, but it should be
ready to go today... OPENJPA-419.
>
>
> > There has been a
> > request for an official release that contains the streaming LOB
> > support, https://issues.apache.org/jira/browse/OPENJPA-130 that is not
> > yet completely documented and not ported to 1.0.2.
>
> As ever, I'm hesitant about porting new features to maintenance
> releases. It could be that parts of OPENJPA-130 are easy enough to
> port in a harmless way, but until I see evidence of that, I'd vote no
> about adding new features to 1.0.2. Instead, we might want to start
> figuring out what needs to be done for 1.1.0.
I agree with this approach. We should discourage the introduction of new
features in the service streams. Having said that, I know there are always
exceptions. Like the discussion that Patrick and I are having about
performance improvements. But, we should treat them as exceptions and
justify them individually instead of just accepting new features into the
service stream.
>
> > I'd also like to start thinking about JPA 2.0 work. How should we
> > handle this? Seems that we would want to call the release that
> > supports JPA 2.0 OpenJPA 2.0. When we do start working on this, should
> > we use the trunk or a branch for it?
>
> That does seem natural.
>
> I think that I prefer making a branch, since we won't be able to
> release JPA2 for some time anyways. Then, we can just track JPA2
> compliance in that branch, and do other new feature / perf work in
> trunk.
> -Patrick
Mike and I were just talking about this yesterday. Given that we put new
features into trunk all the time, adding new function based on JPA 2.0 into
trunk might give us some added benefit from an exposure and testing
viewpoint. If we don't explicitly publicize JPA 2.0 functionality (ie.
claim JPA 2.0 compliance), putting these new features into trunk should be
an okay approach. But, on the other hand...
... As Patrick points out, JPA 2.0 isn't going to be done anytime soon.
There may be additional need from a customer viewpoint to get more
functionality available that is "limited" to the JPA 1.0 spec. Especially
if there are any programming model changes. I'm not aware of any yet, but
that doesn't mean they won't happen in the future.
So, I would propose a hybrid approach. I think a separate branch for JPA
2.0 would be a good way to start. But, as features get solid enough, we
should consider moving them to trunk so that they would get more usage and
exposure. We shouldn't have to wait until JPA 2.0 is complete before moving
individual features to trunk.
Thanks,
Kevin
>
>
> On Jan 31, 2008 12:10 PM, Craig L Russell <Cr...@sun.com> wrote:
> > It looks like we're closing in on a 1.0.2 release. There has been a
> > request for an official release that contains the streaming LOB
> > support, https://issues.apache.org/jira/browse/OPENJPA-130 that is not
> > yet completely documented and not ported to 1.0.2.
> >
> > Are there other features in 1.1.0 that are urgently needed and that
> > can be pulled into 1.0.2?
> >
> > I'd also like to start thinking about JPA 2.0 work. How should we
> > handle this? Seems that we would want to call the release that
> > supports JPA 2.0 OpenJPA 2.0. When we do start working on this, should
> > we use the trunk or a branch for it?
> >
> > 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!
> >
> >
>
>
>
> --
> Patrick Linskey
> 202 669 5907
>
Re: [DISCUSS] Release planning
Posted by Patrick Linskey <pl...@gmail.com>.
> It looks like we're closing in on a 1.0.2 release.
Indeed. I'm planning to go through the unscheduled bugs tomorrow to
get a feeling for other issues that need to be in 1.0.2, and start the
process of trying to get to 1.0.2 readiness over the next weeks.
> There has been a
> request for an official release that contains the streaming LOB
> support, https://issues.apache.org/jira/browse/OPENJPA-130 that is not
> yet completely documented and not ported to 1.0.2.
As ever, I'm hesitant about porting new features to maintenance
releases. It could be that parts of OPENJPA-130 are easy enough to
port in a harmless way, but until I see evidence of that, I'd vote no
about adding new features to 1.0.2. Instead, we might want to start
figuring out what needs to be done for 1.1.0.
> I'd also like to start thinking about JPA 2.0 work. How should we
> handle this? Seems that we would want to call the release that
> supports JPA 2.0 OpenJPA 2.0. When we do start working on this, should
> we use the trunk or a branch for it?
That does seem natural.
I think that I prefer making a branch, since we won't be able to
release JPA2 for some time anyways. Then, we can just track JPA2
compliance in that branch, and do other new feature / perf work in
trunk.
-Patrick
On Jan 31, 2008 12:10 PM, Craig L Russell <Cr...@sun.com> wrote:
> It looks like we're closing in on a 1.0.2 release. There has been a
> request for an official release that contains the streaming LOB
> support, https://issues.apache.org/jira/browse/OPENJPA-130 that is not
> yet completely documented and not ported to 1.0.2.
>
> Are there other features in 1.1.0 that are urgently needed and that
> can be pulled into 1.0.2?
>
> I'd also like to start thinking about JPA 2.0 work. How should we
> handle this? Seems that we would want to call the release that
> supports JPA 2.0 OpenJPA 2.0. When we do start working on this, should
> we use the trunk or a branch for it?
>
> 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!
>
>
--
Patrick Linskey
202 669 5907
Re: [DISCUSS] Release planning
Posted by frankca <fr...@gmail.com>.
Hi Patrick,
That's awesome, sorry for not checking first. Could you please give the ETA
for 1.0.2 release or a link to where it has the release schedule for future
reference?
Thanks,
Frank
Patrick Linskey-2 wrote:
>
> Hi,
>
> That's already in 1.0.2.
>
> -Patrick
>
> On Feb 1, 2008 3:36 PM, frankca <fr...@gmail.com> wrote:
>>
>>
>>
>> Craig L Russell wrote:
>> >
>> > Are there other features in 1.1.0 that are urgently needed and that
>> > can be pulled into 1.0.2?
>> >
>>
>> I'd really appreciate if this critical bug get fixed in 1.0.2 which is
>> already fixed in 1.1.0 TRUNK
>> (http://svn.apache.org/viewvc?view=rev&revision=584463):
>> http://www.nabble.com/Programmatically-pagination-does-NOT-work-with-OpenJPA-1.0.1-to13717713.html
>>
>> Best regards,
>> Frank
>>
>> --
>> View this message in context:
>> http://www.nabble.com/-DISCUSS--Release-planning-tp15213698p15236182.html
>> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>>
>>
>
>
>
> --
> Patrick Linskey
> 202 669 5907
>
>
--
View this message in context: http://www.nabble.com/-DISCUSS--Release-planning-tp15213698p15239349.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: [DISCUSS] Release planning
Posted by Patrick Linskey <pl...@gmail.com>.
Hi,
That's already in 1.0.2.
-Patrick
On Feb 1, 2008 3:36 PM, frankca <fr...@gmail.com> wrote:
>
>
>
> Craig L Russell wrote:
> >
> > Are there other features in 1.1.0 that are urgently needed and that
> > can be pulled into 1.0.2?
> >
>
> I'd really appreciate if this critical bug get fixed in 1.0.2 which is
> already fixed in 1.1.0 TRUNK
> (http://svn.apache.org/viewvc?view=rev&revision=584463):
> http://www.nabble.com/Programmatically-pagination-does-NOT-work-with-OpenJPA-1.0.1-to13717713.html
>
> Best regards,
> Frank
>
> --
> View this message in context: http://www.nabble.com/-DISCUSS--Release-planning-tp15213698p15236182.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>
>
--
Patrick Linskey
202 669 5907
Re: [DISCUSS] Release planning
Posted by frankca <fr...@gmail.com>.
Craig L Russell wrote:
>
> Are there other features in 1.1.0 that are urgently needed and that
> can be pulled into 1.0.2?
>
I'd really appreciate if this critical bug get fixed in 1.0.2 which is
already fixed in 1.1.0 TRUNK
(http://svn.apache.org/viewvc?view=rev&revision=584463):
http://www.nabble.com/Programmatically-pagination-does-NOT-work-with-OpenJPA-1.0.1-to13717713.html
Best regards,
Frank
--
View this message in context: http://www.nabble.com/-DISCUSS--Release-planning-tp15213698p15236182.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.