Hello.
I am +1 to start wrapping up 3.0. I want to create some modeler
documentation for the merge-stuff.
I volunteered to join in on JPA, but lost motivation. At first it
sounded like fun, but then I discovered that it was a lot of work ...
and that I would probably not use it myself. I have a lot of respect
for the work done and still think it is one of the most important
things for cayenne after joining Apache.
Regards,
- Tore.
On 18. juni. 2008, at 15.06, Andrus Adamchik wrote:
> Wanted to float the idea of wrapping up 3.0 release. Contrary to
> what I said in the past (3.0 final == certified JPA release), there
> are a few considerations that made me change my mind in favor of 3.0
> without full/any JPA:
>
> 1. Lack of momentum. We were unable to find any committed volunteers
> to work on the JPA provider, even though we had maybe 5 or 6
> declared volunteers, so I ended up doing all work myself. I have a
> few theories why, but this is not important for this discussion.
>
> 2. My personal availability to do Cayenne work has shrunk
> significantly with growing ObjectStyle consulting business. The
> remaining time is spent on Cayenne classic API, driven by user
> requests and my own needs.
>
> 3. The amount of new features developed in Cayenne classic in 3.0
> requires some serious catching up to do - add modeler support for
> many new features, write tutorials and documentation. In this
> respect I think one thing is very important - communicate to our
> users a clear definition of "what is Cayenne" now (i.e. the scope of
> fully supported features, best practices, etc.). We've done that
> pretty well in the past, but it is impossible to do it with a moving
> target. There are questions being asked like "is there POJO
> support?", "how do I configure cache", etc. All we can do is give a
> vague answer "it sorta work, there's no modeler or documentation").
> With the amount of cool new stuff, I wish we could give users more
> definite answers (or maybe I am too backwards thinking, and in the
> post-Web 2.0 world everybody is comfortable using nightly builds in
> production, and we are wasting time with all the cleanup? :-))
>
> Anyways... Regardless of the limited resources we've managed to
> advance Cayenne 3.0 very far, and regardless of the lack of docs for
> the new features, people love and use them already, so there are
> lots of things to be proud of:
>
> http://cayenne.apache.org/doc/guide-to-30-features.html
>
> So here is the suggested plan. The development part of it is
> presented from the POV of "Andrus as a Cayenne committer" (i.e. the
> stuff I will be working on that does not require PMC consensus and
> does not require others to follow). Release plan part will require
> the PMC consensus.
>
> 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
> * 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
> * Resolve JPA legal caveat [1]
> * (plus lots of smaller features and bug fixes) :
>
> 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.
>
> Thoughts?
>
> Andrus
>
> [1] JPA Legal Caveat: (something to confirm on legal-discuss). We
> are not allowed to release a JPA provider until it fully passes the
> TCK. Per some interpretations of the JPA spec license it seems to
> mean that we can't release a 3.0-final that contains JPA-nonfinal
> provider jars (while we can still release milestone non-final
> releases of JPA). So we'll likely have to fork JPA stuff in a
> separate assembly. That's a minor detail IMO. We can easily comply.
>
This archive was generated by hypermail 2.0.0 : Sat Jun 21 2008 - 02:35:54 EDT