Thanks everyone for your reviews! The only approach I considered for updating the documentation version is a manual one. It looks like this: 1) Checkout to the `website` branch. 2) Build the latest change for the current version, right before the update. 3) Move the build to `public/released-docs/` and rename the directory to the corresponding version. 4) Update the `CURRENT_VERSION` constant, so now it matches the new version. 5) Open a PR.
The Java API docs are built by maven as far as I can tell, so it's not related to the website actually. Regarding the automatization of this process, I've never done anything like this before. Therefore, if you have any suggestions - I'm open to it, I think it should be possible since the workflow is not complex at all. Most likely a small bash script could be enough. Best Regards, Yurii On Tue, Mar 31, 2026 at 3:09 AM Andor Molnár <[email protected]> wrote: > Exactly. My 2 cents are: > > 1. Storing the entire website at a single location is desirable. Given the > proposed > technology changes there’s no clear separation possible without duplicating > website core logic components which will be a maintenance nightmare in the > long term. > > 2. Separate ‘website’ branch or versioned branches. As Patrick mentioned > the docs are versioned and the ability to accompany doc changes with > code changes in the same PR is a big advantage. > > Andor > > > > > > On Mar 30, 2026, at 19:52, Patrick Hunt <[email protected]> wrote: > > > > One reason I remember the docs/api/etc... are part of the source is that > > they are versioned along with it. PRs -- doc changes along with code > > changes also part of the release process. > > > > Patrick > > > > On Mon, Mar 30, 2026 at 5:39 PM Christopher <[email protected]> wrote: > > > >> I think it looks great, but I would really like to see the SCM source > >> for this new site, so I can understand the maintenance/build workflow > >> for it, before I'd have any useful opinion other than regarding > >> aesthetics. > >> > >> I definitely concur with moving the docs out to the site to centralize > it. > >> > >> On Fri, Mar 27, 2026 at 3:03 PM Yurii Palamarchuk > >> <[email protected]> wrote: > >>> > >>> Thanks for your comment, Patrick. > >>> > >>> Why React? > >>> Building a website nowadays is not just HTML + CSS, because doing it > this > >>> way turns the developer experience into a nightmare. With React we > >>> effortlessly have consistent UI components across all pages, including > >>> buttons, tables, markdown rendering, colors, and much more. We also add > >> the > >>> interactivity much more easily with React. A static website doesn't > mean > >> it > >>> lacks interactivity; it often has significant interactivity, especially > >> in > >>> the documentation section. The difference is that we don't need any > >> runtime > >>> environment, we just return the files generated at build time, which > are > >>> ultimately just HTML, CSS, and JS. The website also has dark mode > >> support, > >>> search in the documentation, smooth transitions between pages (no hard > >>> reload), so it gives smooth and better user experience overall. I hope > >> this > >>> answers your question. Moreover, the website will work absolutely fine > >> even > >>> for those who have JS disabled, this is called progressive enhancement. > >>> Initially, the server returns HTML and CSS. The browser renders them > and > >>> tries to fetch the JS files. If it doesn't succeed, the page remains > >>> accessible, though it obviously lacks interactivity. I hope this > answers > >>> your questions, if not, feel free to ask more about it! > >>> > >>> Is it hard for ZK devs to update the content? > >>> Not at all! I tried to make it so the learning curve for non-JS devs is > >>> almost 0. For the documentation you still just need to edit the MDX > >>> (Markdown Extended) files and run the build command. I will also add a > >> bash > >>> script to automate the build process. For the landing pages, you still > >>> mostly only need to modify the markdown files. Only the main page isn't > >>> markdown, modifying something small wouldn't be a problem. In the worst > >>> case, if something more complex is required, you can handle it with the > >> AI. > >>> Nevertheless, the website hasn't been updated for years, so it wouldn't > >> be > >>> a big loss :) > >>> > >>> Best regards, > >>> Yurii > >>> > >>> > >>> > >>> > >>> On Fri, Mar 27, 2026 at 4:19 PM Patrick Hunt <[email protected]> wrote: > >>> > >>>> On Fri, Mar 27, 2026 at 3:32 AM Yurii Palamarchuk < > >>>> [email protected]> wrote: > >>>> > >>>>> Hi there, > >>>>> > >>>>> I am proposing an upgrade to the ZooKeeper website and > >> documentation. We > >>>>> are moving to a modern React.js stack, which allows landing pages and > >>>>> versioned documentation to live in a single application sharing the > >> same > >>>> UI > >>>>> components, libraries, colors, etc. > >>>>> > >>>>> The plan is to move all website and documentation source code to the > >>>>> website branch and remove the zookeeper-docs Maven project from the > >>>> master > >>>>> branch. This decouples the Node/JS build environment from the core > >> Java > >>>>> repository. > >>>>> > >>>>> Versioned docs will be managed via archived folders within the > >> website > >>>>> branch. Documentation updates would move from master to PRs against > >> the > >>>>> website branch. Also I'm not planning to keep the app as a maven > >> project, > >>>>> since it's fully JS based. To keep it simple, I will write a bash > >> script > >>>>> that installs the dependencies, runs the tests, and the build. > >>>>> > >>>>> What do you think about moving the docs out of master to centralize > >> the > >>>>> site? > >>>>> > >>>>> Preview: https://zookeeper-website.vercel.app/ > >>>>> > >>>>> > >>>> Looks pretty slick - nice update and visual refresh! Question though - > >> why > >>>> React? This is a static website, what are the pro/con of React based? > >> Can > >>>> you explain the impact on common use cases like making updates? ZK > team > >>>> includes a number of people, not all of whom might know React, how > hard > >>>> will it be for them to make changes? Impact on the release process? > >>>> > >>>> Regards, > >>>> > >>>> Patrick > >>>> > >>>> > >>>>> Best regards, > >>>>> Yurii Palamarchuk > >>>>> > >>>> > >> > >
