cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Gentry <mgen...@masslight.net>
Subject Re: preparing for 4.0.M2
Date Tue, 02 Dec 2014 16:28:56 GMT
Will the AggregateUtils thing I did be helpful?


On Tue, Dec 2, 2014 at 6:12 AM, Andrus Adamchik <andrus@objectstyle.org>
wrote:

>
> > On Dec 2, 2014, at 1:51 PM, Aristedes Maniatis <ari@maniatis.org> wrote:
> >
> > On 2/12/2014 7:53pm, Andrus Adamchik wrote:
> >>
> >>> On Dec 1, 2014, at 2:06 PM, Andrus Adamchik <andrus@objectstyle.org>
> wrote:
> >>>
> >>> I think I'll actually create a "stable" branch for 4.0.M2, as new
> changes will keep coming in and we want the release to happen
> >>
> >> Which I just did:
> https://github.com/apache/cayenne/tree/4.0.M2_prerelease
> >
> > Cool. There is a lot of great work in there.
>
> Yep. My app code looks so much cleaner after I migrated it to the new
> APIs. And while still raw, the new cdbimport rules.
>
> > I think our previous naming regime would have this branch called
> STABLE-4.0 if we are ready to now make trunk/head available for new work
> that will not land into 4.0.
>
> I didn't give much thought to the branch naming in this instance, as I am
> planning to merge and delete this branch after the release (leaving the tag
> around of course). So it is a short-lived thing.
>
> > If this really is the end of all new features, then perhaps the next
> release will be 4.0-beta1?
>
> There's more query API work planned. We need to align ProcedureQuery and
> NamedQuery, and create a fluent thing for non-selecting SQLTemplates.
> Though these can be done pretty quickly.
>
> A bigger project is to bring all EJBQLQuery functionality into
> ObjectSelect - multi-result selects, aggregate queries, etc. This is more
> challenging. Whether this stuff should be 4.0 or say 4.1 is debatable. I
> feel there's lots of benefit in a quick completion of 4.0. There are users
> who are only allowed to use "GA" tagged dependencies in their work. And by
> the time we get a "full solution", a few years may pass and it won't be as
> exciting by then :) So I am +1 on the Beta idea.
>
> Andrus

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