[Content] Pin docs to released versions
See original GitHub issueContent request
For the time being we will be considering the substrate in the latest polkadot-x.x.x
-release branch the most stable. Docs should thus use these as their baseline and work with these.
Are you willing to help with this request?
Maybe (please specify)
Issue Analytics
- State:
- Created 2 years ago
- Comments:5 (2 by maintainers)
Top Results From Across the Web
Managing releases in a repository - GitHub Docs
To the right of the list of files, click Releases. ... Click Draft a new release. ... Click Choose a tag, type a...
Read more >How To Do Document Version Control (with example)
Learn how to do document version control. It's a way of making sure you know which is the current iteration of a document...
Read more >Chrome Enterprise and Education release notes
The ChromeOS rollback feature enables managed devices to download and run an earlier version of ChromeOS than the one currently installed.
Read more >Release notes for Current Channel - Microsoft Learn
Provides IT Pros with release notes for Monthly Channel releases for ... Microsoft Teams: Pin and hide the room video for Teams Rooms...
Read more >Enable releases and versions | Jira Software Cloud
The Related work feature allows you to add links to your version, so your team members and stakeholders can easily find documents, dashboards,...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
That is what you proposed and we are striving for eventually yes (although I don’t understand the urge to remove archived versions altogether, why?).
But we are talking about different time lines here: even once we have mastered continuous releasing for substrate telling people to always work against
master
with potentially daily breaking changes might not be feasible as the main entry point for people to start with. Meanwhile we can already take steps into the direction that will dramatically improve the situation until we’ve figured out the other problems along the way. This isn’t “either or”, it’s a “steps towards”.I am leaning towards Polkadot release cadence (for now) - https://github.com/substrate-developer-hub/substrate-node-template/issues/260