MapServer 5.0 release plan

[Stephen Woodbridge]

Daniel,

I'm good with this timing also. Pushing it out any earlier will cause it 
to lack the enhancements that would qualify it as a robust 5.0 release.

I think we need to get a priority list of bugs that we plan to tackle 
for 5.0 as well as identifying those that we do not think will get done. 
Obviously all those that are not tagged 5.0 are not part of the plan, 
but I'm think that there are bugs that are relevant to the plan items 
that we do not plan to tackle anyway. For transparency, we should list 
them with their respective items and identify then as X-plan items. For 
general bugs we don't need to be a complete list, but should identify 
those that are must fix for the release. For example, thread-safety 
improvements, I'm sure we have bugs on that, they should be collected, 
listed, and identified as in/out of the plan. Same for other plan items.

There are a lot of good things listed in the Plan, I'm starting to get 
excited to see this shape up and to be able to start playing with some 
of the new features.

-Steve

Daniel Morissette wrote:
> Back in the fall when we released MapServer 4.10 we agreed that we would 
> try to release MapServer 5.0 in the first quarter of 2007.  We have 
> reached that time, but I don't think we are about ready to release 5.0. 
> Very few of the features listed in the 5.0 release plans are complete, see:
> http://mapserver.gis.umn.edu/development/release_plans/mapserver_5_0/
> 
> What do we think are realistic feature freeze and release date for 
> MapServer 5.0?
> 
> The reason I'm asking is that I just got funding approval for the 
> following feature enhancements for MapServer 5.0:
> 
> 1- Redesign of LOG/DEBUG output mechanisms (bugs 709, 1333, 1783)
> 2- Optimize lookup of EPSG codes (bug 1976)
> 3- Integration of Dynamic Charting Capability (bug 1800)
> 4- WMS 1.3 client and server support
> 5- Labelling prioritization (bug 1619)
> 6- Convert mapogr.cpp to use OGR C API (bug 545)
> 
> If I want to have time to do things the right way, including RFC, etc, 
> I'd need at least a good 2 months before the feature freeze. That would 
> mean a feature freeze no earlier than mid-May, or more realistically at 
> the end of May, for a final release around mid-July. Since 4.10.0 was 
> released on October 4th last year, a release mid-July would come 9.5 
> months after the previous one, or 3.5 months late on our 6 months 
> release cycle.
> 
> If the PSC finds that this is too late then I can always reschedule this 
> work until after 5.0, but I think some of those enhancements would be 
> very welcome in a 5.0 release, that's why I am sending this email, to 
> find out what you'd think of a 5.0 feature freeze at the end of May or 
> later, for a release sometimes in July. It's about time that we start 
> talking about dates for the 5.0 release anyway.
> 
> Daniel