[PROJ] PROJ (and GDAL) webpages
Javier Jimenez Shaw
j1 at jimenezshaw.com
Fri Nov 15 12:31:54 PST 2024
On Fri, 15 Nov 2024 at 13:30, Even Rouault <even.rouault at spatialys.com>
wrote:
> 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
>
Looks like you found the proper and nice way to do it, right? Using a tag
(or branch) called "stable". I think that the overhead of the release
process is minimal. In PROJ it would replace the penultimate line from
https://github.com/OSGeo/PROJ/blob/master/HOWTO-RELEASE.md if I understood
correctly.
Do not forget about robots.txt allowing only stable. I think it would make
the indexing more stable (no pun intended initially. Now yes ;), and the
user experience better (finding always "stable", and not an old 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20241115/a2c1b9d2/attachment.htm>
More information about the PROJ
mailing list