I guess it will require some effort to setup and automate the process for supporting multiple versions but afterwards it may be easier to maintain. If the only thing that a committer has to do to update the site is committing to the master then there is not even need for a particular workflow.
On Mon, Dec 9, 2019 at 10:31 PM Julian Hyde <jh...@apache.org> wrote: > We might be inventing requirements here, in order to justify a “cool” > technical change. > > I don’t think there is a strong requirement for multiple versions of the > site. (Sure, it would be nice.) > > This thread started with Stamatis pointing out that it was complicated to > update the site. If we support multiple versions, will this actually make > things less complicated? > > Julian > > > > > On Dec 9, 2019, at 1:23 PM, Stamatis Zampetakis <zabe...@gmail.com> > wrote: > > > > 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 > >> > >
