Francois, in your mail from jan 30, you seem to suggest not to have different versions of the documentation, but only latest. To me that is not an optimal solution to solve the case that we’re low on doc-capacity. In stead I’d suggest to freeze documentation on older versions of geonetwork, but still keep it online for some years, maybe flag it as unmaintained.
Features not available in older versions, but documented, may mislead users (would need a comment: this feature is new since 3.4)
Features with big changes will mislead users (would need a comment: this feature has been redesigned in 3.8)
Features not available in newer versions, how long do you keep it in documentation (would need a comment: this feature has been deprecated in 3.6)
—
Hi,
I don’t think we have resources to maintain one doc per branches and that’s why we changed the website last year with 'Stable version (3.4/3.6/3.8/3.10)". Making (and using) only one link for all would make sense so that the URL is not misleading users https://geonetwork-opensource.org/manuals/trunk/en/index.html (maybe a redirect could be set up in the website ?)
and maybe better identify which features is available in which version in the doc.
Francois, in your mail from jan 30, you seem to suggest not to have different versions of the documentation, but only latest. To me that is not an optimal solution to solve the case that we’re low on doc-capacity. In stead I’d suggest to freeze documentation on older versions of geonetwork,
but still keep it online for some years, maybe flag it as unmaintained.
Features not available in older versions, but documented, may mislead users (would need a comment: this feature is new since 3.4)
Features with big changes will mislead users (would need a comment: this feature has been redesigned in 3.8)
Features not available in newer versions, how long do you keep it in documentation (would need a comment: this feature has been deprecated in 3.6)
We have indication on how to flag new/deprecated features by version https://geonetwork-opensource.org/manuals/3.8.x/en/contributing/writing-documentation.html#versionadded-versionchanged-and-deprecated
but as we don’t dedicate that much energy to this I don’t think the doc is really representative of any versions in time. It has some information but has highlighted in the google summer of doc status document it has a number of areas to be improved.
So indicating “this is the doc for version 3.2.7” would be also quite misleading I think. Having only one doc online make search engine pointing to the most representative version too - which gives end user more chance to find the latest/more up to date info.
Once we could consider a version of the doc representative of a version, then it could make more sense to have per version documentation.
But if you think we should make one doc per version, -0 from me and +1 for adding versionadded, versionchanged and deprecated flags.
Cheers
Francois
—
Hi,
I don’t think we have resources to maintain one doc per branches and that’s why we changed the website last year with 'Stable version (3.4/3.6/3.8/3.10)". Making (and using) only one link for all would make sense so that the URL is not misleading users https://geonetwork-opensource.org/manuals/trunk/en/index.html (maybe a redirect could be set up in the website ?)
and maybe better identify which features is available in which version in the doc.
