<div dir="ltr">As a guy who has been reading the mapserv docs for 20+ years I'll say that I love the format of the docs in general and specifically the version added, version deprecated, etc. Thanks Jeff and all the other contributors. Hopefully I'll be reading the docs for another 20 years.<div><br></div><div>Rich</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 18, 2021 at 3:18 PM Jeff McKenna <<a href="mailto:jmckenna@gatewaygeomatics.com">jmckenna@gatewaygeomatics.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Ah ok Even, your words sunk into me more now, good points. Although I <br>
differ in that I think keeping all of the 'versionadded' references are <br>
very important, as this is the rich information that is so priceless <br>
(knowing when exactly something was added) for both the users and <br>
maintainers of the software/docs. I personally have been making sure to <br>
add those 'versionadded' and 'deprecated since' and 'since version' <br>
notes into the docs, as this information is so useful to users, even in <br>
the case of it being added in 5.0 etc. And as you said, I have to go <br>
get that information in the RFC, which users won't know to check, so <br>
I've been adding those 'since version' references that you mention, to <br>
help users.<br>
<br>
-jeff<br>
<br>
<br>
<br>
On 2021-03-18 5:39 p.m., Even Rouault wrote:<br>
> If we keep a single version for simplicity, we could however decide to <br>
> clean up a bit the doc content to remove mentions of outdated versions <br>
> to avoid cluttering it. There is little point in mentioning any version <br>
> older than let's say 5? years ago. I've done that a bit in the GDAL docs <br>
> a few months ago, removing any mention of GDAL < 2, considering that all <br>
> people looking at the docs would have at least GDAL 2.x something <br>
> available, or if they use antiquated stuff, too bad for them.<br>
> <br>
> Looking a bit at download artifacts, for MapServer we could decide for <br>
> example that the baseline is MapServer 6.4 (or possibly even 7.0 for <br>
> simplicity), and remove any mention of that or older versions (except in <br>
> RFCs that are reflective of history)<br>
> <br>
> "grep -r versionadded en" in the doc repository shows a number of things <br>
> of the 4.x, 5.x or early 6.x eras. 'grep -ri "since version" en' shows <br>
> also a number of potential cleanups.<br>
> <br>
> Even<br>
> <br>
> Le 18/03/2021 à 21:15, Jeff McKenna a écrit :<br>
>> My preference has always been for Option#1, as it is much easier to <br>
>> maintain in my experience, as it is stated clearly as deprecated at <br>
>> the parameter level in the document.<br>
>><br>
>> Speaking openly here, if I was paid fulltime to manage the docs and <br>
>> all the different build versions of the docs, and publishing them <br>
>> online, I could see how that would be possible; but as we are made up <br>
>> of volunteers, I would prefer to keep the single version updated with <br>
>> references to when the feature was added (what MapServer version), and <br>
>> if it is deprecated. I remember recently spending much effort on that <br>
>> in-line versioning improvements, I think that is working nicely now.<br>
>><br>
>> -jeff<br>
>><br>
>><br>
>><br>
>><br>
<br>
<br>
-- <br>
Jeff McKenna<br>
GatewayGeo: Developers of MS4W, MapServer Consulting and Training<br>
co-founder of FOSS4G<br>
<a href="http://gatewaygeo.com/" rel="noreferrer" target="_blank">http://gatewaygeo.com/</a><br>
_______________________________________________<br>
mapserver-dev mailing list<br>
<a href="mailto:mapserver-dev@lists.osgeo.org" target="_blank">mapserver-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/mapserver-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/mapserver-dev</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Richard W. Greenwood, PLS<br><a href="http://www.greenwoodmap.com" target="_blank">www.greenwoodmap.com</a></div></div>