Gerard van Enk <[EMAIL PROTECTED]> skribis: > MMBase 1.6.0 Release Plan > =========================
> Changes > ======= > There are a lot of changes since the last release. Some of the changes > are related to the projects that are included in this distro: > > - MMCI 1.2 > - Editwizards 1.0 > - Security 1.0 > - Taglib 1.0.1 > - Cleaning phase 1 > - Documentation (started, will be finished in MMBase-1.7) > - Richtext 0.x? I propose to call it 0.5. > > Other important changes included in this release are: > - Character encoding is configurable > - New servlets (ImageServlet/AttachmentServer) > - Builder extension builder extension still is 'limited'. This would indicate that some behaviour which would be expected from 'full' builder extension is still lacking. > - Centralized caching (caches.xml) > - Storage Classes > - Automatic builder installation for applications > - Autodection of database > - Use of webapplication server resources (JNDI) + DTD's will be available in the jar (and removed from the config dir) + Improved log-messages > Important bugfixes included are: > - MMBase works inside webapp contexts > - Taglib works with Tomcat 4.1.12 > - Performance issue resolved regarding MMObjectNode::getRelated() and > MMObjectNode::getRelated(type) where type is a builder > > > Release criteria > ================ > Issues to be discussed before the release: > ------------------------------------------ > - SCAN > What will be the status of scan in this release? > - Security > Which security-implementation must be default in this release, > context-security or cloud-security? > - Editwizards > Documentations hasn't been finished, is this a showstopper? I don't think this is a showstopper. It's a petty but documentation can be put online easily. There is some documentation and a bunch of examples. + Excact location of DTD's in jar. + Which 'bugs' of mmbase.org/bug will be showstoppers > Additional criteria > =================== > JDK: > - Sun JDK1.3/1.4 1.4 will not be feasible without some adaptions to the code. This is documented and not very difficult, but it will not be 'out of the box'. Is that enough to assert 'support'? In a similar extend also '1.2' is still supported (some things will simply be missing, but as the situation is now, it will at least build). Perhaps we can say: JDK1.3 and limited support for 1.2 and 1.4. > - IBM JDK1.3 > - Blackdown JDK1.3 > > Servlet Engines: > - Apache Tomcat 4.0.x/4.1.x > - Orion 1.5.2/1.5.4/1.6.0 I think some of us have experience with resin and websphere? It would be a pitty not to include that then. > > Databases: > - MySQL > - Informix > - Hsqldb > - PostgreSQL What tests excactly must be performed to validate as 'supported' (related to app-servers and database)? I myself normally perform (installed in app-server in a context, with a front proxy): - clean installation must succeed (with empty database) - every page of jsp-editors must work - example applications must deploy successfully and work - i perfom the taglib test jsp's in speeltuin/mihxil/test - example editwizards must work - perhaps more can thought of: - junit bridge test must all succeed --> junit tests must be extented for the new functions. - jsp admin pages must work - more? > Releases > ======== I'm glad that there is a release plan now, and that we will freeze. But I also think that the schedule is a little too ambitious. Some remarks. > There will be at least 2 release candidate before the final release. > > Code freeze: > > Start Date: 26-10-2002 > End Date: 02-11-2002 > > During this code freeze most outstanding bugs must be fixed and > stability must be tested. There are quite a lot of open bugs in the bugtracker which must be fixed. I think a week is a little short for them to disappear. Of course this depends on the amount of effort de developer community is going to devote to them in this time. I'd rather see that the end date is not fixed, but determined by the open bug-count, to really enforce the developers to concentrate on _bug fixing only_ (i.e. of course besides _bug hunting_) So this can be shorter or longer.... > > Branch: > > Date: 02-11-2002 > > The branch will be used to create the Release Candidates and after the > 1.6.0 release it will be used for bugfix-releases. In other words I like the branch to be seen only when there is reasonable chance that not every change has to be commited to two branches... Considering the size of the active developers community it is perhaps even not such a bad idea to delay the actual branch (and therefore the freeze) until e.g. rc2. A developer in need of something to code in this period can doubtlessly find a bug to fix by himself. > RC 1: > > Tag Date: 02-11-2002 > Release Manager: Gerard van Enk > > This RC can be used for users outside the developers to test the > upcoming release and report bugs. It can also be used for testing in > different environments (os, jdk, application server, etc). Is there some policy to find users outside the developers? Are they actively contacted? Who will do this? > Maintenance Plan > ================= > The maintenance plan is a plan which describes what to do after the > release is done. Normal development continues on the cvs-head, but it's > possible bugs will be found in this release and cvs-head isn't stable > enough to be released. These bugs must be fixed in the branch which is > created for this release and a minor release will be done (after being > proposed to the community). In any case, no backward-incompatible or > major changes should be made in this branch! I propose (perhaps even volonteer) to automate the build of the 'release branch' as much as possible. I'd only welcome if every minor bug fix will lead to a new build, and the version numbers be pushed to never-heard-of-heights like '1.6.23' or so.... :-) greetings, Michiel -- % Michiel Meeuwissen % [EMAIL PROTECTED] % http://www.purl.org/NET/mihxil/ % Vidu ankaux: http://www.uea.org/katalogo
