graduation: Versionize the documents for every SDKs

[Xuanwo]

Currently, the documentation is only for the latest, which could cause confusion for the end users.

Tasks

• Find ways to versionize the documents for every SDKs, maybe via https://nightlies.apache.org/

[suyanhanx]

I plan to take a snapshot of the website and deploy it on nightlies whenever we make a release.
It will be the place where we distribute historical documents. Also for the latest stable version.
Whereas our website defaults to displaying documents up to the unstable version, it means documents on the main branch are published directly to opendal.apache.org after each commit.

[Xuanwo]

I plan to take a snapshot of the website and deploy it on nightlies whenever we make a release.

So it will be something like https://nightlies.apache.org/flink/flink-docs-release-1.19/?

Potential issues include the need to add a header redirecting users to our most recent documents, and providing links to previous versions of these documents. Do you have a strategy for addressing these concerns?

[suyanhanx]

So it will be something like https://nightlies.apache.org/flink/flink-docs-release-1.19/?

Yes.

Potential issues include the need to add a header redirecting users to our most recent documents, and providing links to previous versions of these documents. Do you have a strategy for addressing these concerns?

It's easy to do this. Docusaurus has provided a convenient way to add the banner. We can also provide links or a page of documents' link list to past versions of the documentation.

[Xuanwo]

Great, would you like to take over this issue?

[suyanhanx]

Great, would you like to take over this issue?

Yep.

[suyanhanx]

Over the past two days, I have been attempting to manually deploy the build of the website to the nightlies.
However, I encountered several strange issues, and I believe that manual deployment is not feasible.
Therefore, I plan to deploy the previous versions of our docs once the secrets are configured, using a temporary workflow.

[Xuanwo]

Therefore, I plan to deploy the previous versions of our docs once the secrets are configured, using a temporary workflow.

We can start deploying since our next release. No bother to build the previous version.

[suyanhanx]

We can start deploying since our next release. No bother to build the previous version.

Thank you. However, I will still consider this option.

I plan to deploy two copies for each version when we do release.
One will be named release-${version}, which will remain unchanged after deployment.
The other one will be named stable, and it will be overwritten when we do release. We need a place where users can quickly access our latest documentation version.

[Xuanwo]

I plan to deploy two copies for each version when we do release.
One will be named release-${version}, which will remain unchanged after deployment.
The other one will be named stable, and it will be overwritten when we do release. We need a place where users can quickly access our latest documentation version.

Simple.

We can run the same deploy twice: one for tagged version, one for stable.

[Xuanwo]

Let me add those logic inside #3739

[Xuanwo]

The UI/UX work could be moved to other thread: #3742