This is my *proposal* intended for a final discussion round and will be followed by a vote of the committers. I will prepare a list of topics to vote upon and post it after the discussion has become silent.
STATUS QUO ----------
Generally, Slide code is in good condition for a release. Still there is some work in the pipeline:
- ACL-12 seems to have come pretty far although updates are yet likely to come
- Wrappers partly seem broken and also need extension
- J2EE / JDBC store still lacks maturity, but is good enough for a beta. Ports to other major databases are still missing. Sybase and MS SQLServer work, Orcale is in my pipeline.
SHOWSTOPPERS
------------
- Authentication wrapper needs fixing
- Docs must be updated, Web as well as internal (CVS)
- J2EE / JDBC store must work
- A STATUS file based on this summary needs to be added to the CVS
- At least all *functional* tests should pass or only fail for known and documented reasons (in release notes)
STUFF NOT GOING INTO THE 2.0 RELEASE ------------------------------------
All classes that do not go into the 2.0 release will be deleted using "CVS remove" directly after the vote. Attic directory will be removed as well.
Kernel (src/share section):
- org.apache.slide.store.StandardStore will be replaced by ExtendedStore along with this the following classes will be deleted from package org.apache.slide.util:
- AbstractObjectCache
- HashMap
- HashMapObjectCache
- Iterator
Stores:
- Package org.apache.slide.store.impl.rdbms will be removed completely and replaced by the merged version in the proposals section
- Package slidestore will be removed completely. Classes from package slidestore.file needed by tx file store will be moved to org.apache.slide.store and will finally vanish with BIND implementation:
- AbstractUriProperties
- UriProperties
JDK SUPPORT ------------
1.3 required, 1.4 recommended
LOGGING -------
Logging API will be augmented by method allowing for both message and throwable in one call. A general redesign of logging is deferred to later releases.
NEW FEATURES ------------
All nwely discussed features go into 2.1 or even later releases, no new features go into 2.0
CODE RESPONSIBILITIES ---------------------
There are no *official* assignments of code responsibilities, but committers are discouraged to change code "associated" to another active commmiter without prior notice.
BINARY RELEASE --------------
There will be one binary release solely consisting of wars (web archive) to be deployed in Tomcat and Weblogic. Another binary release will be Slide bundeled with latest Tomcat jar from the 4.x release for download and go.
CONNECTION TO TOMCAT --------------------
As described under binary release there currently is no alternative to bundeling with Tomcat for full functionality. This is not bad, as Tomcat works fine, is a jakarta project as well and there is existing code to connect Slide to Tomcat. As long as no close bindings to other web or full J2EE container exist, Slide will remain closely connected to Tomcat.
RELEASE PLAN ---------------------
As features contained in the current CVS HEAD are more than enough for a new release and no new features are necessary to have a 2.0 release no milestone releases should be needed. This means the release plan looks rather simple:
- Slide 2.0beta release: 3rd-4th week of Janury 2004 - Slide 2.0final release: 3rd-4th week of February 2004
RELEASE PROCEDURE -----------------
- Releases will be done as described in RELEASE-INFO in the CVS. Although, the name clearly is misleading. Should be renamed. Anyway, this file has been taken over unchanged from the Slide 1.0 release. Here it is for everyone to see:
> We will have the following types of releases (or builds): > > 1 Final releases. These will be of the form x.y. > > 2 Milestone releases. These are of the form x.yMz. Milestone > releases are not supposed to be used in production > environments. Before final releases of the form x.y there will be > milestone builds. > > 3 Bug fix releases (after final releases). These will have two '.'s > in them. People that care about production use will pick x.y.z > where 'y' indicates the last stable release and the greatest > value of 'z' that is available. There will be no milestone > releases between a final release and subsequent bug fix > releases. > > 4 Nightly releases. These are volatile "dynamite" builds. These are > just for the current branch and not between a final release and > subsequent bug fix releases. > > Miscellaneous points: > > 1 Everything except nightly releases are tagged. > > 2 Patches should be submitted with a tag, unless it is obvious. > > 3 Source drops will be available for the last stable release and the > current main branch. > > 4 The committers decide if it is a "go" for a final or bugfix release. > > Release names are of the form x.y[.z]: > > x: API version changes (x >= 3) > y: Non-API features (y >= 0) > z: Bug fixes (z >= 0 and is ommitted if z == 0) >
- As soon as there is a feature freeze (with Apache this is the time of preparing the first beta, I guess) a release branch called SLIDE_2_0 will be created. After that all fixes must be applied to this branch. New features still can be added to the HEAD. The committer is encouraged to merge the changes back to the HEAD immediately or recommit them to the HEAD as well. As this is *likely not to happen* ;) all changes must be merged back to HEAD as soon as the release actually is made.
- As soon as the release goes out, release notes must be checked into the CVS. They should contain general info, fixed bugs, enhancements, known issues, etc. They might be called something like "release-2.0.txt" or similar
STORES ------
Slide 2.0 will feature two fully transactional stores and a fully transactional cache operable with both stores. The default store will be the tx file store as it requires no additional installations. J2EE / JDBC store requires installation of an RDBMS. Depending on contributions yet to come it will support a number of commonly used DBs.
OPEN ISSUES -----------
- How much time is needed to prepare a release, i.e. from feature freeze to actual release?
- What about the web section, containing admin stuff and taglib examples?
- What about src/admin? Does it work, what does it do?
- What about the stuff in src/contribtion? Struts taglib seems to be a nice thing... Does it work? Is it in use? What about the Swing stuff there?
- And the other stuff in src/tablib?
- Wow! There are examples! Did not even notice before... What do they do? Do they work?
Do not know, but certainly have forgotton something important. Folks, please add...
Cheers,
Oliver
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
