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

Document Latch #136

Open
numero-744 opened this issue Nov 2, 2022 · 5 comments
Open

Document Latch #136

numero-744 opened this issue Nov 2, 2022 · 5 comments

Comments

@numero-744
Copy link
Collaborator

Do not merge before SpinalHDL/SpinalHDL#944

Should be added in v1.8? I think new features can get such an "added on vX.X" tag to make things explicit. Is there something for that in Sphinx?

@Dolu1990
Copy link
Member

Dolu1990 commented Nov 2, 2022

Hmm currently, the only thing we had related to specific version is multiple version of the doc (bottom left "v:master" click on it ^^)

Does that works for you ?

@numero-744
Copy link
Collaborator Author

It works and I think it is really useful, but with such features I think it is good anyway to tell "since version XXX you can do this, for earlier versions you have to do that instead", to both explain:

  • what is better to use now
  • what they can find in older code using "legacy" ways to do things, so that they understand it

Also in a company different versions of Spinal can be used for different IPs (because company ITs…) and users will likely read the doc only once therefore they should be aware of these changes.

@Dolu1990
Copy link
Member

Dolu1990 commented Nov 2, 2022

Sure ^^

@wifasoi
Copy link
Collaborator

wifasoi commented Nov 2, 2022

The documentation will generate a new version for each tag. If you want document something for older version of the documentation, you can just rebase and force push (or i can do that)... Not really ideal for contributors, but not a major hurdle either.

For "what best to use now" I think is the job of scalafix for handling deprecation warning and automatic code changes.

@numero-744
Copy link
Collaborator Author

I do not really want to document something for older version, just let the readers know how legacy code can look like to understand it.

Side note: "updating" tags could be a solution to fix pdf build errors in tags for #132, but force-pushing seems not nice for things people might have based their work on. It could be possible to cherry-pick changes on each tag.

For scalafix I am still curious about how to use it, how can it know how to replace things?

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

3 participants