Re: 3.0 tutorial

From: Andrus Adamchik (andru..bjectstyle.org)
Date: Wed Dec 23 2009 - 08:01:45 EST

  • Next message: Michael Gentry: "Another modeler bug ..."

    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.

    Andrus



    This archive was generated by hypermail 2.0.0 : Wed Dec 23 2009 - 08:02:21 EST