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

Publish both the current and next api docs #1245

Closed
ST-DDT opened this issue Aug 8, 2022 · 12 comments
Closed

Publish both the current and next api docs #1245

ST-DDT opened this issue Aug 8, 2022 · 12 comments
Labels
c: docs Improvements or additions to documentation p: 2-high Fix main branch s: accepted Accepted feature / Confirmed bug

Comments

@ST-DDT
Copy link
Member

ST-DDT commented Aug 8, 2022

Clear and concise description of the problem

Multiple users have reported issue caused by the docs page containing docs for the bleeding edge version rather than the current latest release.

Suggested solution

Publish the main docs (page) only during a release.
The latest version should be published to next.fakerjs.dev.

Alternative

None

Additional context

No response

@ST-DDT ST-DDT added c: docs Improvements or additions to documentation p: 2-high Fix main branch s: accepted Accepted feature / Confirmed bug labels Aug 8, 2022
@ST-DDT ST-DDT added this to the v7 - Current Major milestone Aug 8, 2022
@Shinigami92
Copy link
Member

The current only way I could imagine of would be to create a next branch that between PRs and the main branch.
But I'm not sure if we want the maintenance overhead on our side.

@matthewmayer
Copy link
Contributor

another option could be to add @since tags to the documentation, then each method could be annotated in the docs with which version it was added

https://jsdoc.app/tags-since.html

@Shinigami92
Copy link
Member

another option could be to add @since tags to the documentation, then each method could be annotated in the docs with which version it was added

jsdoc.app/tags-since.html

This won't work for deprecation / renaming, would it?
But it is an interesting idea anyways 🤔

@matthewmayer
Copy link
Contributor

I think it might have helped in the fullName example if people could see "added in 7.4.0" in the docs and they know they are using 7.3.1 currently.

@Shinigami92
Copy link
Member

Shinigami92 commented Aug 9, 2022

But then they would look where v7.4 is released, but there is no v7.4 release and they would ask us for that missing release

So it would move the problem just one issue further

@matthewmayer
Copy link
Contributor

Certainly it doesn't solve the whole problem (I think the solution to only update the docs on the website when you release is sensible)

But it would be useful after releases. If I'm running a version a few minor or patch releases old but am referring to the online documentation.

@ST-DDT
Copy link
Member Author

ST-DDT commented Aug 9, 2022

IMO adding @since or not is a separate issue.

@matthewmayer
Copy link
Contributor

note adding @since tags now has its own PR: #1337

@ST-DDT
Copy link
Member Author

ST-DDT commented Sep 22, 2022

Thoughts

  • Create a next branch and develop there. The next branch will be the default branch.
  • The main branch will still be used for the main website, we have to make sure netlify does not take the default branch for the default website.
  • This has to be done before development of v8 starts.

@Shinigami92
Copy link
Member

In last weeks meeting, we discussed to try a branch-process like this:

Today (in shower 😄) an issue raised into my mind!
What will happen with links to the main branch?

Obviously some of them can just be remapped to the next branch. But some historical links that specifically point to e.g. permalinks, do they need the main branch alive?
Or just tweets that contain links referencing the main branch.

@ST-DDT
Copy link
Member Author

ST-DDT commented Oct 2, 2022

But some historical links that specifically point to e.g. permalinks, do they need the main branch alive?

Permalinks reference commits for a reason.

Or just tweets that contain links referencing the main branch.

Why would you reference main explicitly?

@ST-DDT
Copy link
Member Author

ST-DDT commented Oct 13, 2022

Done

@ST-DDT ST-DDT closed this as completed Oct 13, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
c: docs Improvements or additions to documentation p: 2-high Fix main branch s: accepted Accepted feature / Confirmed bug
Projects
No open projects
Status: Done
Development

No branches or pull requests

3 participants