Re: [MMBase-1.6.0] Releaseplan Proposal

[Gerard van Enk]

Michiel Meeuwissen wrote:

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.

Ok, if nobody objects, I'll change this into 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.

And that would be?

These are things that must be added to the releasenotes.

- 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.

Ok, do we need a seperate discussion about this one?

+ Which 'bugs' of mmbase.org/bug will be showstoppers

This must be added to the final releaseplan, but it could be showstoppers wil be found during the process of creating the release.

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.

Ok, but this is something for the releasenotes. I don't think we need to test the release on 1.2, but we'll need to test it on 1.4, that's why I said 1.3 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.

Yep, anybody can test these?

Databases:
- MySQL
- Informix
- Hsqldb
- PostgreSQL

What tests excactly must be performed to validate as 'supported' (related to
app-servers and database)?

That's a good question.

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
-

all examples 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?

That would be something I'd like to address for MMBase-1.7, because developing a good test strategy and testcases is rather complex. A good start will be the bridge tests we allready have.

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.

Well the dates were a little bit of a guess :)

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....

Yes, but I'd like to have some kind of deadline. This deadline could be expanded if needed.

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.

Hmmmm....this is an interesting thought.....I have to think about this one.

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?

There's no policy, any ideas how to 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.... :-)

I don't think automated builds is the answer, but I agree more builds are needed. I'm thinking about something like every quarter of a year a major release, and every 2 or 4 weeks a minor release.

We also have to think how long we're gonna support a release. I think we need to support the previous one or two releases.

Gerard