first of all, many thanks for the great job you're doing! It's a *pleasure* to see Slide resurrecting like this :-)
On 22 Nov 2003, 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.
Orcale? ;-)
No, seriously, I agree with this.
SHOWSTOPPERS ------------ - Authentication wrapper needs fixing
? care to outline this a little more?
- Docs must be updated, Web as well as internal (CVS)
yep
- J2EE / JDBC store must work
+1
- A STATUS file based on this summary needs to be added to the CVS
+1
- At least all *functional* tests should pass or only fail for known and documented reasons (in release notes)
+1
I would like to propose we remove all 'tamino-only' tests since this doesn't really give a good impression of community development.
[no hard feelings on the softwareAG folks, nono, just making sure that this project doesn't look "owned" by SoftwareAG from the outside, reducing the ability to acquire new contributors]
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.
Great.
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
Sounds great.
JDK SUPPORT ------------
1.3 required, 1.4 recommended
+1, even if we don't have any dependency on 1.3 (that I know of), I think awareness of modern JVM is a generally good trend to exhibit.
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.
Good.
NEW FEATURES ------------
All nwely discussed features go into 2.1 or even later releases, no new features go into 2.0
+1, release early, release often.
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.
I would rephrase this in:
There are no assignments of code responsibilities. Committers simply encouradged to pass all tests before committing code to the repository and highly encouradged to promote community discussion before submitting code in case they don't feel familiar with that codebase.
BINARY RELEASE --------------
There will be one binary release solely consisting of wars (web archive) to be deployed in Tomcat and Weblogic.
Would rephrase in "consisting of wars to be deployed in any J2EE container".
Another binary release will be Slide bundeled with latest Tomcat jar from the 4.x release for download and go.
What will be included in the tomcat version?
Also, I would release the client library separately.
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.
As long as there are the two distributions: wars + tomcat, I have no problems with this.
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
I don't know how you can plan a final release, but hey that's up to you as you are the release manager ;-)
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
Have you considered using Maven for the build system? helps a lot in those realms.
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?
that depends on you. you can call the feature freeze right now or you can call the "tree freeze" right before making the release.
note that it takes a few days for the mirrors to be in synch.
- What about the web section, containing admin stuff and taglib examples?
as I said, I'm personally not interested in this, also because it makes heavy dependency on JSP stuff which not everybody is pleased to see and might give the wrong impression to a lot of people (expecially coming from the non-java world and just looking for a webdav repository).
- What about src/admin? Does it work, what does it do?
Have no idea, never used it.
- 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?
the swing stuff is broken, depends on an old version of HTTPClient. couldn't make it work. I would not ship it with the disto and will move it with the client.
- And the other stuff in src/tablib?
never used JSP taglibs.
- Wow! There are examples! Did not even notice before... What do they do? Do they work?
not sure. I looked at the "event interception example" but didn't try to make it work (postponed interception at a later stage).
Do not know, but certainly have forgotton something important. Folks, please add...
There is something that bugs me: Slide creates a session in order to work around WebFolders bugs in authentication. (grep for getSession())
I would love to have a property to disable this behavior as I think it's *very bad* that Slide is non REST-full as a whole just to work around a silly bug in IE.
[note Slide is currently creating a new session everytime the client doesn't have one set: this could be a potential performance killer in environments where cookies are disabled and sessions are transparently cluster replicated, since each request generates a new session!]
-- Stefano.
smime.p7s
Description: S/MIME cryptographic signature
