arrow icon indicating copy to clipboard operation
arrow copied to clipboard

[Docs][Release][Website] Figure out why the version banner code changed in 19.0.0

Open amoeba opened this issue 11 months ago • 4 comments

After we released 19.0.0 and updated the website, I noticed the version banner wasn't set up right. Upon investigating, it looks like the post-10-docs.sh script failed to update the banner code on the stable docs and I didn't notice before merging. I captured more detail in https://github.com/apache/arrow-site/issues/576.

When I grabbed the published version of the 19.0.0 docs, there was a newline that's not usually present in the version banner script:

    <script>
        DOCUMENTATION_OPTIONS.theme_version = '0.16.1';
        DOCUMENTATION_OPTIONS.theme_switcher_json_url = '/docs/_static/versions.json';
        DOCUMENTATION_OPTIONS.theme_switcher_version_match = '';
        DOCUMENTATION_OPTIONS.show_version_warning_banner =
            true; // <---- this is usually on the line above
        </script>

This caused the script's sed command to fail to replace the true with a false. If this happens again, the post-10-docs.sh script will fail so we should figure out what changed before the next release.

amoeba avatar Jan 17 '25 02:01 amoeba

I think we need to update the post-10-docs.sh as the structure of the version banner script will probably stay changed (with newline). This is due to the linter changes applied in the PyData Sphinx Theme repo, see PR with the lint changes and current code in main.

AlenkaF avatar Mar 03 '25 10:03 AlenkaF

I used the following incantation to fix the issue manually but it relies on gnu sed's -z slurp mode option so it's not portable:

find docs -type f -not -path 'docs/[0-9]*/*' -not -path 'docs/dev/*' -print0 \
  | xargs -0 sed -z -i \
    's/DOCUMENTATION_OPTIONS\.show_version_warning_banner =\s*\n\s*true;/DOCUMENTATION_OPTIONS.show_version_warning_banner = false;/g'

assignUser avatar Apr 30 '25 15:04 assignUser

(This is of course not an actual blocker but should ideally be fixed prior to next release to remove the manual intervention)

assignUser avatar Apr 30 '25 15:04 assignUser

I have created a PR that tries to fix this for our next release: https://github.com/apache/arrow/pull/46883

AlenkaF avatar Jun 23 '25 12:06 AlenkaF

Issue resolved by pull request 46883 https://github.com/apache/arrow/pull/46883

AlenkaF avatar Jul 02 '25 05:07 AlenkaF

Thanks for stepping in to fix this one @AlenkaF.

amoeba avatar Jul 02 '25 05:07 amoeba