Hereby a proposal for the releaseplan for the next major release of MMBase.
Please review it and send your comments. Everything can be discussed, but discussion will be closed next tuesday, after this date a vote will take place.
Take a good look at the list of important changes and see if your missing anything.
If somebody is willing to test a certain applicationserver or jdk, please let me know.
It's late, so maybe I forgot something, but he it's a draf :)
Gerard
NOTE: This document is a draft of a release plan for the next release of MMBase. Nothing in this document should be considered authoritative until it has been discussed and approved on the mmbase-dev mailing list.
MMBase 1.6.0 Release Plan
=========================
Objective
=========
The objective of the proposed MMBase release is to provide a stable
MMBase-version, which can be used in a production environment.
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?
Other important changes included in this release are:
- Character encoding is configurable
- New servlets (ImageServlet/AttachmentServer)
- Builder extension
- Centralized caching (caches.xml)
- Storage Classes
- Automatic builder installation for applications
- Autodection of database
- Use of webapplication server resources (JNDI)
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
================
All (big) changes need to be stable, documented and tested.
Bugs:
-----
All bugs from the bugtracker with medium or high priority must be
fixed before this release. Bugs with a low priority can be delayed
untill a future 1.6.x release.
New bugs found during the release proces will only be fixed if there's
a bugreport.
For more information see bugtracker: <http://www.mmbase.org/bug>
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?
Additional criteria
===================
The release needs to tested and found stable with:
OS:
- Linux
- Windows NT, 2000, XP
- Sun Solaris
- MacOS X
JDK:
- Sun JDK1.3/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
Databases:
- MySQL
- Informix
- Hsqldb
- PostgreSQL
Releases
========
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.
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.
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).
RC 2:
Tag Date: 16-11-2002
Release Manager: Gerard van Enk
This RC will be used to determine any showstoppers and decide if there
are more Release Candidates needed.
Final Release:
Code Freeze/Tag Date: 01-12-2002
Release Manager: Gerard van Enk
The final build. Before this release can take place all documentation
and examples needs to be finished, all known bugs need to be resolved
(resolution can also be not fixing it in this release, but these
'known issues' must be described in the documentation) and the
community must approve the final release.
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!
The release team (see below) is responsible for taking care of the
maintenance plan.
Release Team
============
The release team will be composed of the committers that give the binding
+1 on the release plan and release proposal. It must have at least 3
members.
The release team will coordinate the execution of the release plan, dispatch
bugs to volunteers, review commits, and act as a lead in the release
process.
One of the team members will act as "Release Manager" and will be
responsible for building the betas, making the announcements about
the release progress, etc.
After the release is done, the release team is responsible for the
maintenance plan.
