From 6f44de51c06cf7a7397cfd6e2f06320898cd4da3 Mon Sep 17 00:00:00 2001 From: Tom van Woudenberg Date: Fri, 9 Jan 2026 11:29:35 +0100 Subject: [PATCH] Update versions_URLs.md --- book/installation-and-setup/versions_URLs.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/book/installation-and-setup/versions_URLs.md b/book/installation-and-setup/versions_URLs.md index d948409..4561c1d 100644 --- a/book/installation-and-setup/versions_URLs.md +++ b/book/installation-and-setup/versions_URLs.md @@ -6,8 +6,10 @@ If you plan on maintaining only one public version, it is advisable to set `BEHA To share the built book / website of old versions for your book on GitHub you have a few options: - Create a branch for each version. When doing this, [the GitHub workflow](../external/deploy-book-workflow/README.md) will build it on GitHub pages. Here's a few tips: - - It's advised to use the version as branch name. In case of versions per academic year, you can just name each branch to the current academic year, this leads to the URL with the same academic year.. - - It is recommended to update the primary branch as the `PRIMARY BRANCH` when using the [GitHub workflow](gh-workflow-settings) whenever a new version is considered to be the most primary one. This ensures that readers are redirected to a consistent URL, even when new versions of the book are added later. + - It's advised to use the version as branch name, making it very clear which branch to which website. In case of versions per academic year, you can just name each branch to the current academic year, this leads to the URL with the same academic year. In case of book which are more stable over year, you could consider a simpler v1.1. See the page on [TeachBooks versioning](./versioning_changelog.md) for more information about how to name versions (and thus branches). + - You might consider a draft version for each version, in which you collect contributions leading up to a new release of the non-draft versoin. It's advised to name the draft branches so that the link with the non-draft version is obvious. Furthermore, you might consider the [Draft-Release Workflow](../features/draft-release.md) + - Whenever a new version is considered to be the most primary one, it is recommended to update the branch `PRIMARY BRANCH` when using the [GitHub workflow](gh-workflow-settings). This ensures that readers which have visited your book before are redirected to a consistent URL, even when new versions of the book are added later. Furthermore, it revert new readers to the most primary one. + - Set the primary branch (or its draft branch) as the default branch in git, so that that branch is directly visible when people visit your repository. Furthermore, this is probably the branch where you'd like contributers to start from when forking / opening a pull request. - Eventually, you can add old branches to the list of `BRANCHES_ARCHIVED` when using the [GitHub workflow](gh-workflow-settings) to include a banner on the page indicating its archived state. Alternatively, you can add a banner manually to `_config.yml`, as explained [here](../basic-features/banner.md). - If you're using tags (as will be explained in [later](./versioning_changelog.md)), you can create a branch from a tag locally by running: `git branch `. - If you have many version of the book, at some point you might reach the 1 GB GitHub Pages limit. This is only expected for extremely large books with a lot of non-text-based (binary) content. To prevent going over that limit, store large content not used for building the website (like images) on an external server. This can be another GitHub repository or a (paid) object store.