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 <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
