Tasks #8366
closedUpdate ceph.com/docs to default to the latest major release (0.80)
0%
Description
When users go to our docs, it should show the branch for the most recent major release (Firefly).
Users should be able to manually enter master/ or any other version to see other versions of the docs.
This means we can do development on the docs on the master branch for the next release, without worrying about people seeing them before they are baked,
Neil
Updated by Neil Levine over 9 years ago
- Assignee changed from John Wilkins to Alfredo Deza
Updated by Alfredo Deza over 9 years ago
- Status changed from In Progress to Resolved
/docs/ now redirects to the latest (0.80.5 at the moment)
And will get updated as soon as there is a new release
Updated by John Wilkins over 9 years ago
- Status changed from Resolved to Fix Under Review
- Assignee changed from Alfredo Deza to Sage Weil
We need to review this a bit further. Pointing to the latest major release is fine, but we need to have a way to cherry pick commits for the docs. Currently, all doc updates go to master except for new features, which are put into either a wip branch or next. When a commit for master needs to appear in the latest major release, we should define the procedure for putting the commit into that release so that it displays.
This is particularly important for getting started issues and distro-specific issues people encounter that get addressed after the release is already out to customers, but before a point release where docs get backported.
Updated by Sage Weil over 9 years ago
John Wilkins wrote:
We need to review this a bit further. Pointing to the latest major release is fine, but we need to have a way to cherry pick commits for the docs. Currently, all doc updates go to master except for new features, which are put into either a wip branch or next. When a commit for master needs to appear in the latest major release, we should define the procedure for putting the commit into that release so that it displays.
This is particularly important for getting started issues and distro-specific issues people encounter that get addressed after the release is already out to customers, but before a point release where docs get backported.
There are a few pages like release-notes too that are a bit awkward to freeze like that. Although.. it might actually make it cleaner because you'd see the latest point release at the top of the list instead instead of the last dev release. Hmm. So backporting those at least is pbly fine.
I think we just need to change the workflow to make backporting docs part of the process. Given the amount of stuff that has happened since firefly, we can either do a huge doc backport spree, or we can wait until giant or hammer and start backporting from there. Up to you guys I think which you want to do.
To sync up firefly, it might be simpler to do a simple cp -a on the docs dir in one big commit instead of cherry-picking the hundreds of commits since then...
Updated by Ian Colle over 9 years ago
- Status changed from Fix Under Review to In Progress
- Assignee changed from Sage Weil to John Wilkins
Updated by Alfredo Deza over 9 years ago
John any updates on this? It is a bummer that we have all the infrastructure/services ready to deal with the redirects and we can't.
Updated by John Wilkins over 9 years ago
- Assignee changed from John Wilkins to Alfredo Deza
Can we update it to the latest major release with the backports--e.g., v0.80.7? I finally have someone to help with the upstream, so we can begin cherry picking commits as needed.