Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Explore helping users to distinguish between test and stable lib versions #821

Open
lread opened this issue Sep 3, 2023 · 4 comments
Open

Comments

@lread
Copy link
Member

lread commented Sep 3, 2023

Recently

I got Clojure analyzing successfully on cljdoc

And I noticed...

That cljdoc will, but default, navigates the user to docs for the latest non-SNAPSHOT release.
At the time of this writing, this is 1.12.0-alpha4

But...

The current stable release is 1.11.1.

And if...

We navigate to clojure 1.11.1, we see:
image

So...

I suggest that we distinguish versions that are considered test releases.

Supposing that clojure 1.11.1 is the current stable release and 1.12.0-alpha4 is the latest test release, I think we should auto-navigate 1.11.1.

Where we show a tip for the current release:

  • if the user is viewing 1.10.0, they should see:
    • current stable is 1.11.1
    • current test is 1.12.0-alpha4
  • if the user is viewing 1.11.1 they should see:
    • current test is 1.12.0-alpha4
  • if the user is viewing 1.12.0-alpha4
    • current stable is 1.11.1

But what are the rules to distinguish?

I think there are conventions for version qualifiers in test releases: alpha, beta, rc.

I'll poke around a bit. Clojars distinguishes stable from alpha in their badges, I'll see what they do. Antq does not, by default anyway, include test releases, I'll see what they do.

I'll also take a peek at the maven docs and see if they have anything consistent to say here.

@lread
Copy link
Member Author

lread commented Sep 3, 2023

@tengstrand do you have some opinion on this one?
I notice that clj-poly currently only uses the alpha qualifier in its version scheme.

So I'd have to take that kind of use case into consideration too.

Perhaps a different way to go about it would be to navigate to the current latest non-SNAPSHOT release but show, if available, the current latest stable release (which technically, clj-poly does not currently have).

@tengstrand
Copy link

Sorry for late response, but we can close this now.

My plan is to always build a snapshot release when committing things to the master branch, and people that work against the master branch can therefore always use the snapshot version.
People that use the poly tool, they can use the non-snapshot version of the clj-poly documentation, that is build when we release the tool.

@lread
Copy link
Member Author

lread commented Sep 7, 2023

Oh no, this one is different, I raised this one!

I wanted it to be easy for folks to distinguish between test and stable releases of library docs.

@lread lread changed the title Explore intrepretation of lib version qualifiers Explore helping users distinguish between test and stable lib versions Sep 7, 2023
@lread lread changed the title Explore helping users distinguish between test and stable lib versions Explore helping users to distinguish between test and stable lib versions Sep 7, 2023
@tengstrand
Copy link

Okay, cool!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants