The final releaseplan for the next version of MMBase.
This is majority call, with a margin of 3 votes.
Please pay attention: two votes must be made: 1 for releaseplan and 1 for the releaseteam (releaseteam at least requires 3 members).
LINKS:
Attached document.
START OF CALL: 2002-10-26 0:30
END OF CALL: 2002-10-30 0:30
I agree with the proposed releaseplan:
[_] +1 (YEA)
[_] +0 (ABSTAIN )
[_] -1 (NAY), because :
[_] VETO, because:
I'd like to be part of the releaseteam
[_] +1 (YEA)
[_] +0 (ABSTAIN, if you don't know yet)
[_] -1 (NAY)
Gerard
Ps. The reason why the final release will not be 2 weeks after the rc2 but a litte more, is I'm gone that weekend :)
NOTE: This is the final version of the release plan for the next release of MMBase. After this document has been approved by the commitors on the developers list, nothing in this document can be changed without a new vote.
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.5
Other important changes included in this release are:
- Scan has been turned off by default
- Character encoding is configurable
- New servlets (ImageServlet/AttachmentServlet), these are
replacements for parts of the servdb servlet.
- Builder extension (not completely finished)
- Centralized caching (caches.xml)
- Storage Classes
- Automatic builder installation for applications
- Autodection of database
- Use of webapplication server resources (JNDI)
- DTD's are 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.x (version 4.1.12 is the first version
it's working)
- Performance issue resolved regarding MMObjectNode::getRelated() and
MMObjectNode::getRelated(type) where type is a builder
- Performance workaround for context/cloud security (possible to grant
read privilege to everyone)
- Nodes are always returned with the correct type of builder
- Security can be set in no-read-check mode
- Connection pool can run on a lower amount of connections
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>
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
- IBM Websphere
- Resin versie?
- Jetty versie?
Databases:
- MySQL
- Informix
- Hsqldb
- PostgreSQL
- Hypersonic
(*) Because there are no real testcases for every part of MMBase the
following testplan must be used before MMBase can be found stable on a
certain platform/jdk/servletengine/etc:
- clean installation must succeed (with empty database)
- every page of jsp-editors must work
- example applications must deploy successfully and work
(most applications can be tested using an example from the mmexamples
dir)
- example editwizards must work
- all examples must work
Releases
========
There will be at least 2 release candidate before the final release.
Code freeze:
Start Date: 30-10-2002
End Date: 08-11-2002
During this code freeze most outstanding bugs must be fixed and
stability must be tested.
If there are more problems found during the freeze, or fixing the most
important bugs takes more time, the duration of the freeze may be
extended.
Branch:
Date: 08-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: 08-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: 22-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: 11-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.
