In the short term we should try to do our best to follow the existing workflow.
In the medium term we shall hope that things will be easier with the automated build of the website. In the longer term, I would really prefer to migrate towards a solution like the one proposed by Vladimir. As I also mentioned in a previous email, there are many projects who publish multiple versions of the doc and I find this very helpful. People usually wait some time before updating their libraries to the latest release; in this and other cases it is helpful to have a couple versions of the doc available online. On Sun, Dec 8, 2019 at 11:02 PM Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: > 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 >
