Update publication date / add status section

[chrberndt]

Since this #1180 issue has been fixed, I think the publication date #1180 should be updated too.

Additionally, I'd like to suggest to add version information on the published site, too. Perhaps similar to the version selector of https://lexicondesign.io/

[matuzalemsteles]

hey @chrberndt, that's a great idea, I've been thinking about it too. It is important to inform you what we have changed and in what version the documentation is related to the packages, we still have things to improve on our documentation to make it clearer. We'll be working on it...

hey @jbalsas what do you think about it?

[jbalsas]

Hey @chrberndt, @matuzalemsteles, Lexicon has a selector because they keep a reference to the previous major version 1.x.x.

Our closest thing to 1.x.x is actually https://lexiconcss.wedeploy.io/, which is a very different thing.

Docs in both cases (Lexicon and Clay) always refer to the state of the latest release.

I think it should be straightforward to simply add the latest released version somewhere in the docs. Pinging @victorvalle to see if they can offer a proposal for it 👍

[jbalsas]

Added to https://github.com/liferay/clay/milestone/15 so we can prioritize it :)

[kresimir-coko]

Can we get some clarification on this task? I don't see a version selector/publication date/status on the Lexicon site. Also, https://lexiconcss.wedeploy.io/, is down, so I can't reference it to even figure out what this task is supposed to achieve.

[chrberndt]

@kresimir-coko perhaps an example from a more reliable documentation:

https://docs.gradle.org/current/userguide/userguide.html

With regard to a more agile release cycle, I think it would be very useful to have a version switcher similar to the one of the gradle docs.

With regard to partner- and community-developers an explanation of which version of clay / lexicon applies to which version of our products would be great as well. The latter information should be available on the front-page of the documentation as well.

[kresimir-coko]

@kresimir-coko perhaps an example from a more reliable documentation:

https://docs.gradle.org/current/userguide/userguide.html

You're referring to this part of the UI?

Which versions would we have and what would they link to, can you be specific?

[chrberndt]

Yes, exactly. I'm aware of https://v2.clayui.com/ and next.clayui.com (3.x). And what I like about the gradle docs as well is the alias for the current version and the link to the archive ("All versions").

@jbalsas and @plhnk - maybe you want to get in touch with each other since the documentation requirements for lexicon and clay seem very similar. From a developer point of view, I'd very much appreciate a consistent approach for documentation - at least in the realm of front-end design and development.

[kresimir-coko]

It seems that https://next.clayui.com/ === https://clayui.com/
So the only version other than the default (clayui.com) would be v2.clayui.com.
Does that warrant a dropdown, or just a link next to the logo to the v2 version, and vice versa, link to v3 on the v2.clayui.com?

[chrberndt]

Well - with currently two options, you're right. But I'd expect more versions in the future and since we offer support for at least four years, customers should have easy access to the documentation that applies to their respective version.

[kresimir-coko]

So perhaps we should wait on confirmation by @jbalsas or @bryceosterhaus whether to pursue this and in what manner.

[bryceosterhaus]

I'm not totally sold on the idea of adding a dropdown for different versions. This might be helpful in the future, but right now I think the technical limitations on this would be a bit much. It would require us to cut releases of docs for each package, and we just haven't been doing that. This grows even more difficult since we now have different versions for each package(button vs alert). This might be something we re-visit in the future, but as of now I think it's too much for our current limitations.

In the future we may look into migrating each package's docs to its own README in the package and that way it would be versioned with each release.

[bryceosterhaus]

Going to close this for now since we don't see ourselves adding this. We may re-visit once we start to version our site based on our release cycle.