This 4.4 release plan has been agreed between the developers. However the information below may still change slightly as the release progresses.

Planned Dates

Based on our experience with 4.2.0, we will plan for 3 betas over a 6 weeks period after the code freeze. This would lead us to a final release around endof November:

• Feature/Code? freeze - October 17th (done)
• 4.4.0-beta1 - October 21st
• 4.4.0-beta2 - November 3rd
• 4.4.0-beta3 - November 15th (done on Nov 21st)
• 4.4.0 (final) - November 29th (done)

CVS Tags/Branches?

• The main trunk (HEAD) in CVS is currently the 4.3 development version that we plan to release as 4.4
• The stable CVS branch for this release will be called "branch-4-3" (not created yet).
• Current proposed date for creating "branch-4-3" is the date of the 4.4.0 release (around Nov 29th)
• If post-4.4 developments require earlier branching then please bring up your request for branching on the -dev list.
• The betas will be tagged in CVS as "rel-4-4-0-beta1", "rel-4-4-0-beta2", ... and the releases as "rel-4-4-0", "rel-4-4-1", etc...

Bugzilla Conventions

In order to facilitate querying the bugzilla database for bugs that still need to be addressed for this release, we try to stick to the following conventions:

• Bugs to be addressed for this release must have their target milestone set to "4.4 release"
• Bugs/Enhancements? that can't make it in this release but that we may want to address at a later time should be marked with the "FUTURE" target milestone with a comment explaining that the bug is postponed and if possible a quick analysis
• The target milestone on a bug should be set by the developers (bug owners) and not by the users (reporters).

Other good practices when dealing with bugs:

• Please file bugs for any non-trivial bugfix or change to the software. This is so that we keep a trace for future reference of all bugfixes and changes that were made (why and how).
• Please mark bugs ASSIGNED as soon as you start working on them
• Please when marking a bug fixed include a comment describing the fix, the version of the software in which it was done, and any other relevant information. This will just make our lives easier in a few months/years when questions come up about this issue.
• When committing to CVS, please include the bug number in your CVS change log comment.
• Keep documentation in mind when fixing/changing things: if you cannot update the documentation yourself then please create a documentation bug describing the new feature/change and which document(s) should be updated.

The following query returns all currently open bugs that are tagged with the "4.4 release" target milestone: http://mapserver.gis.umn.edu/bugs/buglist.cgi?target_milestone=4.4+release&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED

Open Tasks

• Documentation updates - Coordinate with all documentation contributors to bring all documents up to date for the release
  • Resp: Kari
  • Bug #:
  • Status:

• Connection Pooling - Expose to SWIG MapScript
  • Resp: Sean
  • Bug #:
  • Status:

• Dump data from imageObj to filehandle (swig mapscript)
  • Resp: Sean
  • Bug #: [#941]
  • Status: core code in place, soliciting typemap contributions from scripting language users.

• • Resp:
  • Bug #:
  • Status:

Completed Tasks

Once completed, the tasks above should be moved down here.

• Connection Pooling - SDE
  • Resp: Howard
  • Bug #: [#942]
  • Status: Connection pooling for SDE has been implemented using the new connection pooling API, and under my testing appears to be working well. One change that was made is that SDE versions are now specified in the DATA definition of the layer rather than the CONNECTION. The only place that I know of documentation showing how to use SDE versions in MapServer was in the wiki, and I don't think the change will be that disruptive, as I think the number of users of this feature is small. If people do not have versions specified anywhere, SDE.DEFAULT is used as before with (hopefully) no ill effects. Thread locking on the SDE connection has been applied using SDE's locking facility. See the source code for more information.

• FastCGI
  • Resp: Frank
  • Bug #:
  • Status: complete, only tested with WMS so far.

• Connection Pooling - core and PostGIS
  • Resp: Frank
  • Bug #:
  • Status: apparently complete for 4.4, multi-threadsafe version likely left to post 4.4.

• Dynamic class creation (swig mapscript)
  • Resp: Sean
  • Bug #: [#939]
  • Status: Complete

• writeQuery/saveQuery (swig mapscript)
  • Resp: Sean
  • Bug #: [#921]
  • Status: done, awaiting confirmation from reporter

• Internationalization (iconv)
  • Resp: Julien/Daniel?
  • Bug #: [#858], [#909], [#1017], [#911]
  • Status: Implementation complete. Doc pending in bug [#890].

• WCS Server
  • Resp: Steve
  • Bug #:
  • Status: Done.

• Time support in WMS
  • Resp: Assefa
  • Bug #: [#872]
  • Status: Implementation done. Docs (HOWTO) live.

• Connection Pooling - Oracle
  • Resp: Fernando
  • Bug #:
  • Status: Done in beta2.

• Map Context support in mapserver cgi
  • Resp: Assefa
  • Bug #: [#946]
  • Status: code done. QA done. Docs updated.

• Support for Z shapefiles
  • Resp: Assefa
  • Bug #: [#869], [#870], [#871]
  • Status: php mapscript functions are done(870). Swig version done (871).

• Try to cleanup the PHP/regex mess
  • Resp: Daniel
  • Bug #: [#520]
  • Status:

• Review open bugs and try to get all critical ones fixed before code freeze, or at least flagged with "4.4-release" target milestone.
  • Resp: All developers
  • Bug #: n/a
  • Status: