<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 16 Nov 2024 at 00:26, Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.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"><u></u>

  
    
  
  <div>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_quote">
          <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
            <div>
              <p>EDIT: actually looking at <a href="https://docs.readthedocs.io/en/stable/versions.html" target="_blank">https://docs.readthedocs.io/en/stable/versions.html</a>,
                I do read "If you want a custom <code><span>stable</span></code>
                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<br>
              </p>
            </div>
          </blockquote>
          <div>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 <a href="https://github.com/OSGeo/PROJ/blob/master/HOWTO-RELEASE.md" target="_blank">https://github.com/OSGeo/PROJ/blob/master/HOWTO-RELEASE.md</a>
            if I understood correctly.<br>
          </div>
          <div><br>
          </div>
        </div>
      </div>
    </blockquote>
    <p>That's not so simple. There is no concept of automatic aliasing a
      git banch to another one. You can resync between them at will, but
      that must be done each time. So we'd likely need a tiny script
      doing something like:</p>
    <p>git checkout stable<br>
      git fetch origin 9.5<br>
      git merge origin/9.5  # should be a forward merge (ie not merge
      commit)<br>
      git push origin stable<br></p></div></blockquote><div>Wouldn't it be easier with a "tag" ? Just set (or re-set with -f) the tag "stable" to the needed commit (that can be another tag, like "9.5.1")<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><p>
      <br>
      and running it regularly (at least each time a commit in 9.5
      affects the doc)<br></p></div></blockquote><div>After every change in doc? I would expect that stable is the last released version. If there is anything changed in the doc, it will be in the next release (or when we consider it important like the GDAL survey)<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><p>
      <br>
      and when releasing a new 9.6 version, at release time, recreating
      the stable branch it with<br>
      <br>
      git checkout stable<br>
      git fetch origin 9.6<br>
      git reset --hard origin/9.6<br>
      git push -f origin stable<br></p></div></blockquote><div>The same as above. <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><p>
    </p>
    --
    <pre cols="72"><a href="http://www.spatialys.com" target="_blank">http://www.spatialys.com</a>
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.</pre>
  </div>

</blockquote></div></div>