Excellent! 100% support from me, this is exactly what we needed. I think you should put it somewhere on the site, once it has been discussed.
As for discussion, I see nothing wrong with it. For the open issues, I say we leave the taglib for a later release if it is not directly needed now. Richie On Sat, 2003-11-22 at 00:05, Oliver Zeigermann wrote: > I understand that everyone had the chance to contribute to the threads > on 2.0 release and that they for the present time have come to an end. > > 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] > >
signature.asc
Description: This is a digitally signed message part
