On the whole, I agree. For my thinking anyway, the JPA compliance is
somewhat of a distraction from the original design style of Cayenne.
It is an move (to some extent) to make Cayenne have a Hibernate-like
interface. I suspect many people come to Cayenne because it isn't
Hibernate-like.
I think if we leave aside the JPA compliance, there is so much in
Cayenne 3.0 that is worthy of a major release point. It is stable and
very useful. And attempting a roughly yearly release cycle is probably
not a bad thing.
On 18/06/2008, at 11:06 PM, Andrus Adamchik wrote:
> DEVELOPMENT:
>
> JPA is still on the table, only postponed till the future releases
> (3.1). For now concentrate on wrapping up classic API features. Here
> is an approximate (and pretty long) list:
>
> * EJBQL missing features (constructors, flattened relationships,
> better error reporting)
> * Vertical Inheritance
As I've earlier indicated both Marcin and Lachlan are going to spend
some ish work hours in the next month on various Cayenne tasks,
particularly inheritance. That task has been languishing for far too
long since I had the burst of energy in the planning phase a while
ago. I'll work with them to get that code tested and committed.
> * Multiple cayenne.xml in the project (CAY-943)
> * Generating Query and Procedure Access Code (CAY-1070)
> * Modeler SoC 2008
> * Modeler: support for embeddables
> * Modeler: support for EJBQL queries
> * Tutorials
Does this mean cleaning up the examples within the web documentation
now, or updating the projects which are little working demos? To my
mind, effort on the online documentation is more valuable than effort
on the projects.
> * Resolve JPA legal caveat [1]
Since there is no copyright over the concept of JPA itself, could this
be satisfied by simply ensuring that nothing mentions that Cayenne is
JPA compliant or partially-compliant?
> * (plus lots of smaller features and bug fixes) :
* How about the generified SelectQuery? I know it was discussed to
death and there was no 100% clean method, but it might be nice to get
in given 3.0 is the Java 5 release.
Maybe now is a good time to create 4.0 and 3.1 milestones and start
triaging tasks into those?
> RELEASE PLAN:
>
> * Once major remaining features are in, we change releases suffix
> from Mx to Bx ("milestone" to "beta") and go into the code freeze.
> * Once we fix all bugs and write docs, we do release candidates
> (somewhere here we also branch for 3.1 development)
> * We release 3.0-final
> * We EOL 1.2 (SourceForge) and 2.0 (Apache) branches.
Might be good to support the 2.0 branch for critical bug fixes for 12
months? Doesn't look like there will be any given its current stable
nature, but it might create confidence.
I suspect given your goals above, a few beta releases, etc we might be
aiming for a final 3.0 release toward the end of the year. Does that
sound right to you?
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
This archive was generated by hypermail 2.0.0 : Wed Jun 18 2008 - 11:10:34 EDT