You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by Andrus Adamchik <an...@objectstyle.org> on 2008/10/22 16:46:45 UTC
M5?
We got a bunch of tasks closed and new tasks started since we had this
discussion last time. So is everybody ok with tagging M5 or are there
reasons to wait longer?
I did a round of testing and bug fixing last week, and I feel like the
current state of the trunk is fine for a milestone release. I also
have two major in-progress tasks - inheritance and addressing prefetch
limitations, but there is no reason to hold the release for those.
Andrus
Re: M5?
Posted by Tore Halset <ha...@pvv.ntnu.no>.
Hello.
I am all +1 to a M5.
My current focus is to look at the locking issues in DataRowStore
(CAY-1124) and hopefully clean up some of the external synchronization
on it. It is progressing very slowly as I have not been able to
reproduce the issue in a junit test.
- Tore.
On Oct 22, 2008, at 16:46, Andrus Adamchik wrote:
> We got a bunch of tasks closed and new tasks started since we had
> this discussion last time. So is everybody ok with tagging M5 or are
> there reasons to wait longer?
>
> I did a round of testing and bug fixing last week, and I feel like
> the current state of the trunk is fine for a milestone release. I
> also have two major in-progress tasks - inheritance and addressing
> prefetch limitations, but there is no reason to hold the release for
> those.
>
> Andrus
>
Re: M5?
Posted by Aristedes Maniatis <ar...@ish.com.au>.
On 23/10/2008, at 6:45 PM, Andrey Razumovsky wrote:
> Also I foresee I will soon work with ROP much more, and I'd like
> some other
> features on ROP to be done, like maybe lifecycle callback-like
> functionality. So I'd rather we limit "no more API changes" later than
> sooner.
Of course, 'no more API changes' doesn't mean forever :-) Just that
if we have a goal to aim for, then if you miss that goal, it just
means that the next set of API changes go into 3.1 (or 4.0).
So we can:
1. Decide on a feature set which will go into 3.0 then move all other
features in Jira to 'future'. If new features come in they go to
'future' and don't get added to the infinitely increasing list that is
3.0. OR
2. Decide on a date by which all new features are to be committed.
Then after that comes just bug fixing. This date based approach is
being used by a number of larger projects (such as FreeBSD).
Also, we should decide as a matter of principle, can the API change
between 3.0 and 3.1? Or wait until 4.0? Personally I think that API
changes should be allowed between 3.0 and 3.1 otherwise we split
development into too many branches.
Ari Maniatis
-------------------------->
ish
http://www.ish.com.au
Level 1, 30 Wilson Street Newtown 2042 Australia
phone +61 2 9550 5001 fax +61 2 9550 4001
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: M5?
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Oct 23, 2008, at 3:45 AM, Andrey Razumovsky wrote:
> I agree that it's high time for M5. As for CAY-1077, Andrus, how
> exactly
> would you like this dialog to behave?
Let's start a separate thread on that.
>
> I'm currently working on CAY-1119, this is nested contexts for ROP.
> In fact,
> half of the work is already done on the trunk. Still, I have some
> nested
> tests failing yet. Anyways, this is major commit and requires API
> change
> (moving methods up from DataContext to BaseContext and
> ObjectContext) and
> surely be after M5.
Could you elaborate on what changes you envision in the ObjectContext
interface?
> Also I foresee I will soon work with ROP much more, and I'd like
> some other
> features on ROP to be done, like maybe lifecycle callback-like
> functionality. So I'd rather we limit "no more API changes" later than
> sooner.
I am sure that will take sometime until the beta feature freeze. We'll
still allow occasional API changes related to bug fixes. Also we can
fork a branch for 3.1 (or create a STABLE branch for 3.0, and develop
3.1 on trunk) if needed, so the new stuff can be developed in parallel
with stabilizing the final release. And then by the date of 3.0 final
people won't care about it, as trunk will have a bunch of new cool
things :-). Anyways, there are fairly straightforward ways to
accommodate your own development priorities and the release schedule.
Andrus
Re: M5?
Posted by Andrey Razumovsky <ra...@gmail.com>.
Hello
I agree that it's high time for M5. As for CAY-1077, Andrus, how exactly
would you like this dialog to behave?
I'm currently working on CAY-1119, this is nested contexts for ROP. In fact,
half of the work is already done on the trunk. Still, I have some nested
tests failing yet. Anyways, this is major commit and requires API change
(moving methods up from DataContext to BaseContext and ObjectContext) and
surely be after M5.
Also I foresee I will soon work with ROP much more, and I'd like some other
features on ROP to be done, like maybe lifecycle callback-like
functionality. So I'd rather we limit "no more API changes" later than
sooner.
Andrey
2008/10/23, Andrus Adamchik <an...@objectstyle.org>:
>
> We always wanted shorter cycles between the major releases, and we could
> never implement that in practice (even when I was working on Cayenne full
> time). But we should definitely try.
>
> The problem is too many things that get started in parallel, each taking
> lots of effort to make it production quality throughout the stack.
>
> In regards to 3.0, I think my initial list is still mostly valid:
>
> http://markmail.org/message/ynuaswnpgenindsn
>
> so except for the SoC tasks (thanks to amazing job done by Andrey), there's
> still a bunch of half-baked things. Let me comment on the individual items:
>
> * EJBQL missing features (constructors, flattened relationships, better
> error reporting). I guess constructors and error reporting can be moved to
> 3.1; flattened relationships is a must IMO.
>
> * Vertical Inheritance. This turned into a horizontal inheritance effort,
> but done in a generic way, so we are advancing all types of inheritance at
> once. Still need to do the hardest parts of the runtime.
>
> * Multiple cayenne.xml in the project. No progress on that yet. As much as
> I'd think of this as a killer feature, this is a good candidate for 3.1.
> Sigh... I'd really love an ability to define listeners in the mapping
> created outside of the main Cayenne mapping project. Otherwise the listener
> concept doesn't scale well at all. I am very frustrated with the current
> rigid implementation.
>
> * Generating Query and Procedure Access Code. This is done for
> SelectQueries; need to add support for other queries, and better Modeler
> support.
>
> * Modeler: support for embeddables. This can probably remain a "stealth"
> feature in Cayenne. We can add Modeler support in 3.1
>
> * Modeler: support for EJBQL queries. We need that.
>
> * Tutorials. Maybe we don't have to ship tutorial code with the download
> (we stopped doing that with 3.0M1), and keep it documentation only... But it
> would be nice to add extra things to the existing tutorials, such as
> listeners.
>
> * (new) Modeler support for flattened attributes. Runtime supports them for
> many months, still most users can't take advantage of it.
>
>
> I don't have the rights to create milestones in Jira, but some triage work
>> to organise remaining tasks might be useful.
>>
>
> I added you to cayenne-admin group. You should have this permissions now.
>
> Andrus
>
> On Oct 22, 2008, at 6:47 PM, Aristedes Maniatis wrote:
>
>> On 23/10/2008, at 1:46 AM, Andrus Adamchik wrote:
>>
>> We got a bunch of tasks closed and new tasks started since we had this
>>> discussion last time. So is everybody ok with tagging M5 or are there
>>> reasons to wait longer?
>>>
>>
>>
>> Absolutely. It has been long enough since M4. For that matter, once we
>> resolve the API changes surrounding generics, what is preventing a release
>> of 3.0? I think it would be good for the public visibility of Cayenne to
>> have a final release of 3.0 soon. If it were not for the API effects of
>> moving to generics m4 could well have been labelled 3.0 and this coming
>> release 3.1.
>>
>> I believe we are already advocating to people that they use 3.0M4 in
>> production, so we should formalise that with a properly labelled release.
>> Should we agree to:
>>
>> 3.0M5: next week
>> 3.0M6: inheritance and prefetch (and other bits which are in progress
>> now), plus finalisation of generics
>> 3.0 beta 1: no more API changes
>>
>> I don't have the rights to create milestones in Jira, but some triage work
>> to organise remaining tasks might be useful.
>>
>>
>>
>> Regards
>> Ari
>>
>>
>>
>>
>> -------------------------->
>> ish
>> http://www.ish.com.au
>> Level 1, 30 Wilson Street Newtown 2042 Australia
>> phone +61 2 9550 5001 fax +61 2 9550 4001
>> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>>
>>
>>
>>
>
Re: M5?
Posted by Andrus Adamchik <an...@objectstyle.org>.
We always wanted shorter cycles between the major releases, and we
could never implement that in practice (even when I was working on
Cayenne full time). But we should definitely try.
The problem is too many things that get started in parallel, each
taking lots of effort to make it production quality throughout the
stack.
In regards to 3.0, I think my initial list is still mostly valid:
http://markmail.org/message/ynuaswnpgenindsn
so except for the SoC tasks (thanks to amazing job done by Andrey),
there's still a bunch of half-baked things. Let me comment on the
individual items:
* EJBQL missing features (constructors, flattened relationships,
better error reporting). I guess constructors and error reporting can
be moved to 3.1; flattened relationships is a must IMO.
* Vertical Inheritance. This turned into a horizontal inheritance
effort, but done in a generic way, so we are advancing all types of
inheritance at once. Still need to do the hardest parts of the runtime.
* Multiple cayenne.xml in the project. No progress on that yet. As
much as I'd think of this as a killer feature, this is a good
candidate for 3.1. Sigh... I'd really love an ability to define
listeners in the mapping created outside of the main Cayenne mapping
project. Otherwise the listener concept doesn't scale well at all. I
am very frustrated with the current rigid implementation.
* Generating Query and Procedure Access Code. This is done for
SelectQueries; need to add support for other queries, and better
Modeler support.
* Modeler: support for embeddables. This can probably remain a
"stealth" feature in Cayenne. We can add Modeler support in 3.1
* Modeler: support for EJBQL queries. We need that.
* Tutorials. Maybe we don't have to ship tutorial code with the
download (we stopped doing that with 3.0M1), and keep it documentation
only... But it would be nice to add extra things to the existing
tutorials, such as listeners.
* (new) Modeler support for flattened attributes. Runtime supports
them for many months, still most users can't take advantage of it.
> I don't have the rights to create milestones in Jira, but some
> triage work to organise remaining tasks might be useful.
I added you to cayenne-admin group. You should have this permissions
now.
Andrus
On Oct 22, 2008, at 6:47 PM, Aristedes Maniatis wrote:
> On 23/10/2008, at 1:46 AM, Andrus Adamchik wrote:
>
>> We got a bunch of tasks closed and new tasks started since we had
>> this discussion last time. So is everybody ok with tagging M5 or
>> are there reasons to wait longer?
>
>
> Absolutely. It has been long enough since M4. For that matter, once
> we resolve the API changes surrounding generics, what is preventing
> a release of 3.0? I think it would be good for the public visibility
> of Cayenne to have a final release of 3.0 soon. If it were not for
> the API effects of moving to generics m4 could well have been
> labelled 3.0 and this coming release 3.1.
>
> I believe we are already advocating to people that they use 3.0M4 in
> production, so we should formalise that with a properly labelled
> release. Should we agree to:
>
> 3.0M5: next week
> 3.0M6: inheritance and prefetch (and other bits which are in
> progress now), plus finalisation of generics
> 3.0 beta 1: no more API changes
>
> I don't have the rights to create milestones in Jira, but some
> triage work to organise remaining tasks might be useful.
>
>
>
> Regards
> Ari
>
>
>
>
> -------------------------->
> ish
> http://www.ish.com.au
> Level 1, 30 Wilson Street Newtown 2042 Australia
> phone +61 2 9550 5001 fax +61 2 9550 4001
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>
>
>
Re: M5?
Posted by Aristedes Maniatis <ar...@ish.com.au>.
On 23/10/2008, at 1:46 AM, Andrus Adamchik wrote:
> We got a bunch of tasks closed and new tasks started since we had
> this discussion last time. So is everybody ok with tagging M5 or are
> there reasons to wait longer?
Absolutely. It has been long enough since M4. For that matter, once we
resolve the API changes surrounding generics, what is preventing a
release of 3.0? I think it would be good for the public visibility of
Cayenne to have a final release of 3.0 soon. If it were not for the
API effects of moving to generics m4 could well have been labelled 3.0
and this coming release 3.1.
I believe we are already advocating to people that they use 3.0M4 in
production, so we should formalise that with a properly labelled
release. Should we agree to:
3.0M5: next week
3.0M6: inheritance and prefetch (and other bits which are in progress
now), plus finalisation of generics
3.0 beta 1: no more API changes
I don't have the rights to create milestones in Jira, but some triage
work to organise remaining tasks might be useful.
Regards
Ari
-------------------------->
ish
http://www.ish.com.au
Level 1, 30 Wilson Street Newtown 2042 Australia
phone +61 2 9550 5001 fax +61 2 9550 4001
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: M5?
Posted by Kevin Menard <ni...@gmail.com>.
Yeah, the problem if you will, is that we disagreed on how that should
behave. I feel like by bringing up the next column with a single
click that it confuses the actual relationship path. It threw me for
a loop initially.
I was really hoping someone other than you, Andrey, or me could weigh in on it.
--
Kevin
On Wed, Oct 22, 2008 at 6:12 PM, Andrus Adamchik <an...@objectstyle.org> wrote:
> Hmm, checking this now (the trunk version; do I need to patch anything?) ...
> It still requires doubleclick to navigate and single click to select. I
> think it should be the other way around.
>
> Andrus
>
>
> On Oct 22, 2008, at 5:29 PM, Kevin Menard wrote:
>
>> I'd like to close out the issue related to relationship modeling
>> improvements. I'm just looking for people to try it out and give
>> opinions. If no one else tries it out, I'll just pick an option and
>> close it out:
>>
>> https://issues.apache.org/cayenne/browse/CAY-1077
>>
>> --
>> Kevin
>>
>>
>>
>> On Wed, Oct 22, 2008 at 10:46 AM, Andrus Adamchik
>> <an...@objectstyle.org> wrote:
>>>
>>> We got a bunch of tasks closed and new tasks started since we had this
>>> discussion last time. So is everybody ok with tagging M5 or are there
>>> reasons to wait longer?
>>>
>>> I did a round of testing and bug fixing last week, and I feel like the
>>> current state of the trunk is fine for a milestone release. I also have
>>> two
>>> major in-progress tasks - inheritance and addressing prefetch
>>> limitations,
>>> but there is no reason to hold the release for those.
>>>
>>> Andrus
>>>
>>
>
>
Re: M5?
Posted by Andrus Adamchik <an...@objectstyle.org>.
Hmm, checking this now (the trunk version; do I need to patch
anything?) ... It still requires doubleclick to navigate and single
click to select. I think it should be the other way around.
Andrus
On Oct 22, 2008, at 5:29 PM, Kevin Menard wrote:
> I'd like to close out the issue related to relationship modeling
> improvements. I'm just looking for people to try it out and give
> opinions. If no one else tries it out, I'll just pick an option and
> close it out:
>
> https://issues.apache.org/cayenne/browse/CAY-1077
>
> --
> Kevin
>
>
>
> On Wed, Oct 22, 2008 at 10:46 AM, Andrus Adamchik
> <an...@objectstyle.org> wrote:
>> We got a bunch of tasks closed and new tasks started since we had
>> this
>> discussion last time. So is everybody ok with tagging M5 or are there
>> reasons to wait longer?
>>
>> I did a round of testing and bug fixing last week, and I feel like
>> the
>> current state of the trunk is fine for a milestone release. I also
>> have two
>> major in-progress tasks - inheritance and addressing prefetch
>> limitations,
>> but there is no reason to hold the release for those.
>>
>> Andrus
>>
>
Re: M5?
Posted by Kevin Menard <ni...@gmail.com>.
I'd like to close out the issue related to relationship modeling
improvements. I'm just looking for people to try it out and give
opinions. If no one else tries it out, I'll just pick an option and
close it out:
https://issues.apache.org/cayenne/browse/CAY-1077
--
Kevin
On Wed, Oct 22, 2008 at 10:46 AM, Andrus Adamchik
<an...@objectstyle.org> wrote:
> We got a bunch of tasks closed and new tasks started since we had this
> discussion last time. So is everybody ok with tagging M5 or are there
> reasons to wait longer?
>
> I did a round of testing and bug fixing last week, and I feel like the
> current state of the trunk is fine for a milestone release. I also have two
> major in-progress tasks - inheritance and addressing prefetch limitations,
> but there is no reason to hold the release for those.
>
> Andrus
>
Re: M5?
Posted by Michael Gentry <bl...@gmail.com>.
I've been pretty out-of-the-loop lately, but have no objections to an M5.
On Wed, Oct 22, 2008 at 10:46 AM, Andrus Adamchik
<an...@objectstyle.org> wrote:
> We got a bunch of tasks closed and new tasks started since we had this
> discussion last time. So is everybody ok with tagging M5 or are there
> reasons to wait longer?
>
> I did a round of testing and bug fixing last week, and I feel like the
> current state of the trunk is fine for a milestone release. I also have two
> major in-progress tasks - inheritance and addressing prefetch limitations,
> but there is no reason to hold the release for those.
>
> Andrus
>