RFC 19: style and label attribute binding...

[Steve Lime]

Keep in mind that we ain't talking about a major breakage. 99% of applications do
not use the current binding support that exists. 

I'm not aware of other RFCs or even just ideas in the back of someone's mind that
would require map.h structural changes that would cause compatability issues. Are there
examples that folks are thinking about specifically?

Steve

>>> Stephen Woodbridge <woodbri at SWOODBRIDGE.COM> 6/8/2006 12:56:38 PM >>>
Frank,

This is exactly my point, I may have been too subtle on this point.

This would have a major impact on DM Solutions, Where2GetIt and lots of 
others. It would be really bad to fracture PHP and SWIG mapscripts any 
more than they are now, I think we need DM Solutions to weight in on 
this also.

That said, if we are going to break, then lets really clean it up. This 
might include (in a separate RFC) more changes to support thread safety, 
better architecture for .NET and Java support if we need that etc. These 
are the things that would really justify a major breakage.

-SteveW

Frank Warmerdam wrote:
> Steve Lime wrote:
>> I'm all for consistency in point releases but major releases give us 
>> the opportunity
>> to clean things up a bit. Even in those cases disruption should be 
>> minimized. In this
>> case I would advocate a clean up...
> 
> Folks,
> 
> If we are going to break compatibility I would hope we would use the
> opportunity to do some serious cleanup.  I'd add that breaking mapscript
> applications is as serious as break pure mapfile based applications to my
> mind.  And every time we do that we lose people who end up stuck back on
> ancient versions of mapserver because they don't have the time / knowledge
> to fix things up for a new version.  Folks trapped on old versions like
> this are hard to help, and don't generally get to contribute much useful
> to the community.   This is my way of saying I hate breaking backward
> compatibility.
> 
> That said, if we were to do so at an obvious point like the move to 5.0
> at least is should be pretty understandable.  Much worse to break
> compatibility going from 4.6 to 4.8 for instance.
> 
> Best regards,