<html>
<head>
</head>
<body style="font-variant: normal; margin-bottom: 1px; margin-left: 4px; line-height: normal; font-style: normal; font-size: 12pt; font-family: Comic Sans MS; font-weight: normal; margin-top: 4px; margin-right: 4px">
<p style="margin-bottom: 0; margin-top: 0">
<font face="Comic Sans MS" size="3">All,</font> </p>
<br>
<p style="margin-bottom: 0; margin-top: 0">
<font face="Comic Sans MS" size="3">Wouldn't it be easiest to just make a version stamped copy of documentation whenever a release goes out the door? Then just keep editing the main documentation. The biggest piece then is just removing deprecated stuff on a schedule I would think.</font> </p>
<br>
<p style="margin-bottom: 0; margin-top: 0">
<font face="Comic Sans MS" size="3">It might make some sense to also make a function -> version matrix at some point as well as a quick reference. I've had occasion to wonder when a function made it's way into the product and at what version. We regularly have had multiple versions in production at once for example. This would also quickly show the stuff removed and when, and even be a good spot to show where replacement functions took effect (which recently happened in some areas.)</font> </p>
<br>
<p style="margin-bottom: 0; margin-top: 0">
<font face="Comic Sans MS" size="3">bobb</font> </p>
<br>
<p style="margin-bottom: 0; margin-top: 0">
<br>
<br>
>>> Jeff McKenna <jmckenna@gatewaygeomatics.com> wrote:<br> </p>
<table border="0" style="margin-bottom: 0; margin-left: 15px; font-size: 1em; margin-top: 0; margin-right: 0" bgcolor="#f3f3f3">
<tr>
<td>
<div style="border-left: solid 1px #050505; padding-left: 7px">
<p style="margin-bottom: 0; margin-top: 0">
Hi Steve,<br><br>My position is that the doc contents should contain references to the<br>MapServer version that the feature applies to.  So yes we should<br>maintain backwards compatibility.  For example, /mapfile/expressions.txt<br>could be separated into "MapServer 6.0 Expressions" and "MapServer 5<br>Expressions" sections.  I would argue that this is much easier to<br>maintain, and makes more sense to a user.  It does ask doc contributors<br>and developers to specifically mention the MapServer version when they<br>are documenting though.  I'll give an example of what I mean:<br><br>Let's say I am a mapscript dev and I add a function to a mapscript.<br>Then I'd go to its doc (meaning: in trunk and also in<br>branch-whatever-is-live-on-web, because a user wants to know what is<br>available) and add:<br><br>GetXXX<br>   Added in MapServer version 6.2, this function gets the...<br><br><br><br>I hope this helps clarify my position.<br><br>-jeff<br><br><br><br>On 11-07-21 1:42 PM, Steve Lime wrote:<br>> Question for folks. What's our position regarding multi-version support<br>> within the documentation? For example, there were a number of syntax<br>> changes related to logical expressions in 6.0. We could update the<br>> documentation to reflect 6.0 "as is" with no references to how things<br>> worked in older versions. We could also try to maintain some backwards<br>> compatibility so that the documentation could support all versions.<br>> Doing so requires lots of extra explanation though and makes it harder<br>> to maintain. If documentation is version specific then that would argue<br>> for historical documentation to be made available...<br>><br>_______________________________________________<br>mapserver-dev mailing list<br>mapserver-dev@lists.osgeo.org<br><a href="http://lists.osgeo.org/mailman/listinfo/mapserver-dev">http://lists.osgeo.org/mailman/listinfo/mapserver-dev</a><br>
</p>
</div>
</td>
</tr>
</table>
</body>
</html>