2009/12/19 Steve Bennett <[email protected]>: > On Sun, Dec 20, 2009 at 12:28 AM, Cartinus <[email protected]> wrote: >> >> What this is also very good for, is pointing out all the "broken" stuff in >> the >> default Osmarender rules. Like the values for shop tags under amenity and >> the >> values for religion tags under denomination. >> >> They are redlinked, not supported by the other things in the list and not >> used >> according to OSMdoc. > > I think this is a pretty important question, and as others have pointed out, > shows a failing in Osmarender. IMHO, renderers should *not* support endless > numbers of deprecated tags, or should only do so in limited circumstances.
Deprecation makes sense in software projects but not so much in OSM unless we start to approach the database more like a code repository. There's an unwritten rule that when you deprecate/remove a feature, it's up to you to correct all the usages in the current repository and any other repositories you have access to, in the same atomic commit. If you remove a feature and fail to update the usages, you break the build (in our terms you break the rendering of some area on the opposite side of the planet), and that's always a bad thing and you may lose commit access. (Same if you don't write an appropriate comment for your change). This is even more difficult when you're deprecating a library's api. You have to make sure that for at least some time the old API works but the users are shown a deprecation warning (I guess in OSM terms that could mean sending out messages). As a minimum you have to update the examples in your repo. That's why there's a policy of first adding as little api as possible, because it's always easy to add entry points and difficult to remove them. Cheers _______________________________________________ talk mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk
