A MapServer 5.0 Branch? (Re: RFC 17: Dynamic Array Sizing)
Steve Lime
Steve.Lime at DNR.STATE.MN.US
Mon May 15 23:53:12 EDT 2006
But is it *enough* to warrant 5.0 is the question. Perhaps with full GEOS support in MapScript, the WxS support for MapScript, Postgresql joins, relative coordinate definition, label prioritization, hardness control ;-) and other goodies it is enough for 5.0.
If I knew there were some folks interested in working on Cairo support or XML input into existing structures (via expat) then I would argue those types of additions would be big enough in and of themselves for 5.0 and might lobby for a 4.10 in the interim.
In the end they are just version numbers so perhaps I worry too much...
Steve
>>> Paul Spencer <pspencer at DMSOLUTIONS.CA> 05/15/06 9:23 PM >>>
Support for curved text is a user-facing improvement, IMO. And so is
dynamic allocation of mapfile objects ... just different users with a
different pain :)
What happened to calling 5.0 the Hawaii release?
On 15-May-06, at 8:58 PM, Steve Lime wrote:
> I agree on the feature list- been thinking about that for some
> time. My thoughts were that major revisions should have a number of
> user facing improvements. The dynamic arrays wouldn't qualify in my
> opinion so they should be part of the next 4.x release. Should a
> couple of larger enhancements materialize soon then perhaps we
> could skip 4.10. I do think we should shoot for something pre-
> conference if for no other reason that to get the curved labels out
> there...
>
> Steve
>
>>>> Sean Gillies <sgillies at FRII.COM> 05/15/06 3:44 PM >>>
> Steve,
>
> I think that the fact that it touches so many files is more an
> argument *for* a branch than against. Anyhow, I'm just happy if some
> milestones get set for 5.0. That's not to say that I feel that there
> must be a 5.0 (or even a 4.10 for that matter) before the conference,
> but it would be great to start listing the features for the next
> versions.
>
> Sean
>
> On May 15, 2006, at 10:44 AM, Steve Lime wrote:
>
>> I kinda agree that a branch probably isn't necessary. This touches
>> so many =
>> files
>> that merging will be a pain in the butt. I think we're a bit out
>> from a =
>> 4.10/5.0 release
>> so that there's still ample time to implement and fix.
>>
>> Steve
>>
>>>>> Frank Warmerdam <warmerdam at POBOX.COM> 5/15/2006 10:08 AM >>>
>> Sean Gillies wrote:
>>> Maybe this work could be done in a new branch and we could take=20
>>> advantage of the opportunity to ditch some unsupported or
>>> outdated=20
>>> aspects of MapServer: non-OGR mysql, image maps, flash, cartoline.
>>
>> Sean,
>>
>> I don't see why it needs to be in a distinct branch. The more I
>> see how
>> things work in the GeoTools project, the more I am nervous about
>> experimental branches for "next generation" technology.
>>
>>> It's funny that I made a very similar proposal about 2 years ago,
>>> but=20
>>> the response from other developers at the time was "YAGNI".
>>> =20
>>> http://mapserver.gis.umn.edu/cgi-bin/wiki.pl?
>>> RefactoringObjectCollectio=
>> ns=20
>>
>> I'm not sure what YAGNI means (Yet Another Gillies New Idea?) but
>> skimming
>> the proposal I think it is more radical than anything I'm proposing
>> and
>> consequently more disruptive.
>>
>>> Frank, count on me for help with testing the effects on Python
>>> mapscript.=
>>
>>
>> Thanks, I appreciate that!
>>
>> Best regards,
>> --=20
>> ---------------------------------------
>> +-----------------------------------=
>> ---
>> I set the clouds in motion - turn up | Frank Warmerdam,
>> warmerdam at pobox.c=
>> om=20
>> light and sound - activate the windows | http://pobox.com/
>> ~warmerdam=20
>> and watch the world go round - Rush | President OSGF, http://
>> osgeo.org
+-----------------------------------------------------------------+
|Paul Spencer pspencer at dmsolutions.ca |
+-----------------------------------------------------------------+
|Applications & Software Development |
|DM Solutions Group Inc http://www.dmsolutions.ca/|
+-----------------------------------------------------------------+
More information about the mapserver-dev
mailing list