Hello, The process for updating the website is still a bit involved so people can easily get it wrong. I am reviving this thread to refresh people's memories around this topic.
I also raised a PR [1] as an attempt to improve the respective instructions. Feedback is welcome, especially from people who haven't touched the website so far. Best, Stamatis [1] https://github.com/apache/calcite/pull/2708 On Thu, Dec 12, 2019 at 9:08 AM Francis Chuang <[email protected]> wrote: > My plan is to get automated site builds up and running first, which > should get rid of the most difficult/troublesome steps for updating the > site. > > We can then evolve/experiment with the site to improve the process further. > > On 12/12/2019 6:28 pm, Stamatis Zampetakis wrote: > > 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 <[email protected]> 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 <[email protected]> > >> 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 < > >>> [email protected]> 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 > >>>> > >> > >> > > >
