Francis>There are also links to Avatica docs in Francis>the side bar and it would be a bit strange to have them always point to Francis>the master version of Avatica.
gradle.properties references the Avatica version, so we could print the appropriate links. Michael>that need to be made that are independent of a particular release Michael>(e.g. adding a commiter)? Michael>Would I go back and edit the previous Michael>release branch? No. You update committers on a master branch Michael>Do we somehow label parts of the site as being Michael>release-independent? It makes little sense to discuss. The answer will be obvious once someone tries. Michael>Even if this is the case, consider when we might Michael>have to correct documentation errors from a revious release The current ASF rule is to have rel/... tag for each release. That is the site build script could use rel/vX.Y tags to get "released versions". Then there are at least two strategies. a) If we want to update documentation for calcite-1.10.0, then we could release calcite-v1.10.1. b) If a "silent" update is required (e.g. fix typo), then we could invent "support/vX.Y" branches, and commit the fix to that branch. Note: the current release process does not require a "release branch". The build script does NOT create new commits to the source repository. However, we could create one on-demand (e.g. in case we really need to patch the old site version or back-port a fix) Vladimir
