cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <>
Subject Re: 3.0 tutorial
Date Wed, 23 Dec 2009 13:01:45 GMT

On Dec 23, 2009, at 12:50 AM, Aristedes Maniatis wrote:

> I've got all that resolved now.

Great. That's good news.

> But I'd like to spend a little time before our launch on various  
> tidying. Ideally I'll do it all in one go close to launch so we can  
> name 3.0 as stable, move 1.x/2.x into an older archived section, etc.
> If you make any changes, please make sure you change all 6 (?)  
> spaces we have in the same way, and commit the template into svn. I  
> think I might be lagging a bit in committing my latest changes to svn.

I guess I'll let you handle it.

> Javadocs are building nicely in Hudson now, but I want to push that  
> out to the web site in the same URL as they are now (the existing  
> doc building broke a few weeks back so they are not updating....  
> probably that mvn install problem). In theory I could do version 3.0  
> and trunk as separate javadocs if people will find that helpful.

Yes, splitting trunk (3.1) from 3.0 stuff will be very helpful for all  
pieces of the documentation, including javadocs. Here is some thoughts  
on that:

* 3.1 UserGuide is quickly diverging from 3.0. Currently we publish  
3.1 UG under 3.0 menu, we need to publish 3.0 version there.

* Same with 3.1 Javadocs - 3.1 Javadocs is quickly diverging from 3.0.  
Currently it is published under 3.0, that is likely to cause confusion.

* Very soon we'll have a separate "version 3.1" top menu item, having  
all the trunk stuff linked to it. Until we do, we don't have to  
publish the trunk docs, but publishing 3.0 docs is important, cause we  
want people to switch ASAP. (This also goes for changing the status of  
3.0 in the menu to "Beta", or "Release Candidate").

A bit unrelated thing about 3.1 Javadocs... as we are moving in the  
direction of more fine grained modularity (either visible or invisible  
to the end user), we either need to split the javadocs by  
"unpublished" module, including at least "cayenne-di-unpublished" and  
"cayenne-jdk1.5-unpublished", and leaving room for more, or we  
generate a single javadoc from the aggregated module - cayenne-server.


View raw message