Javier,
I have the impression (maybe I misunderstood) that both the automatic
redirection and the robots should be pointing to "stable". (GDAL
didn't have "stable" url at the beginning, I know)
That will make search engine indexers don't have to remake the index,
with the consequent degradation in the position. Also will not point
somebody to an old version of the software. It is good that the old
versions are there in case you need it, but search engines should
point to "stable" (and IMHO not to latest, with functionalities that
are may not be released yet).
What do you think?
The annoying thing with "stable" is that it points to the latest
released *tag*, not the head of the release branch, so bugfixes in the
doc after the release don't appear until the next one.
There was a problem in PROJ after the last release. Maybe we can fix
it to be ready for the next release in a couple of weeks.
Refresh our minds about which problem you're thinking too (don't we
spend our time solving problems) :-) ?
One problem I've in mind with the "stable" RTD tag is that when you
prepare the release, you need in advance to update the doc to advertize
the release *before* creating the tag. For example
https://proj.org/en/stable/download.html doesn't point to the 9.5.0
release, because the commit that advertizes it was done just after. For
GDAL, I've adjusted the release procedure so that step is done in advance.
Bottom line: I would be in favor of pointing to "stable" if we could
tweak the RTD configuration to point to a branch of our choice, but I
don't think that's currently possible.
Another thought: the GDAL user survey currently advertized on gdal.org
couldn't be advertized if the default was the stable RTD tag
EDIT: actually looking at
https://docs.readthedocs.io/en/stable/versions.html, I do read "If you
want a custom |stable| version, create either a tag or branch in your
project with that name.". So maybe we should just create a git "stable"
branch, but that means we need to regularly resync it to the actual HEAD
of the active 9.x git branch
--
http://www.spatialys.com
My software is free, but my time generally not.
Butcher of all kinds of standards, open or closed formats. At the end, this is
just about bytes.
_______________________________________________
PROJ mailing list
PROJ@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/proj
