- Swap the "build" and "gen" terms used in this repo to match
what we do in other repos. "gen" generates a bunch of files, which
is needed by "build". Unlike other repos, the output of "gen" doesn't
need to be checked in to Git however.
- The clean target now cleans the generated directory.
- Makefile.core.mk now defines SOURCE_BRANCH_NAME that decides which
branch we get reference material from. This makes it much simpler to
switch branches.
- Added the "update_all" target which does all the work needed to pull
in the imported content.
- Substantially simplify logic that deals with releases & release notes.
- Make it easier to add a new release to the site. THere are fewer things to
change as the site infra can figure more stuff out on its own.
- Make it so release notes can be added in one language without require them
to be added in the other language.
- Replace the ugly "a new version is available" callout on older release note
pages with a popup that only shows up when you click on the download button.
- Auto-generate tables of template->adapters and adapter->templates
- Make the "Edit this page on GitHub" menu option track the branch correctly instead of always pointing to master.
- Update the reference docs.
- Move some strings from the footer to the translation table so they can be translated.
- Use a custom search engine for the preliminary site, so the preliminary site can actually be searched.
- Improve a few shortcodes to improve how they work when nested in tabs.
- Move a few constants out of the layouts and into args.yml for cleanliness.
- Remove the release-specific wording on the main release note page and on the docs page. This
ends up being hard to keep correct and not really useful.
- Add a full_version variable in args.yml which contains the 3 part release version
such as 1.0.1. When we release a new patch, we need to update this number in the current
release branch.
- Apply the full_version variable to the download button on the home page. It will now say "DOWNLOAD 1.0.1".
- Within a code block, you can now surround a relative file path with @@. This will
cause the path to be rendered as a link to raw.githubusercontent.com/istio/istio/<path>.
This lets the user click on the link to see the content of the file, which is mighty
handy.
- Updated all code blocks to take advantage of the above.
- Introduce support for {{< branch_name >}} which returns the source code branch
name associated with the current doc site.
- Use {{< branch_name >}} in all our references to content in istio/istio on GitHub. This thus
pins our references to the correct version of the content in GitHub. This prevents errors from
gradually appearing in our doc set as content in GitHub starts to diverge from the expectation
in the site content.
(cherry picked from commit 1dcd301)
- Within a code block, you can now surround a relative file path with @@. This will
cause the path to be rendered as a link to raw.githubusercontent.com/istio/istio/<path>.
This lets the user click on the link to see the content of the file, which is mighty
handy.
- Updated all code blocks to take advantage of the above.
- Introduce support for {{< branch_name >}} which returns the source code branch
name associated with the current doc site.
- Use {{< branch_name >}} in all our references to content in istio/istio on GitHub. This thus
pins our references to the correct version of the content in GitHub. This prevents errors from
gradually appearing in our doc set as content in GitHub starts to diverge from the expectation
in the site content.
Martin Taillefer
Martin Taillefer
John Howard
Eric Van Norman
Andra Cismaru