Tasks #8366
closed
Update ceph.com/docs to default to the latest major release (0.80)
Added by Neil Levine almost 10 years ago.
Updated almost 9 years ago.
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
- Assignee changed from John Wilkins to Alfredo Deza
- Target version set to sprint14
- Status changed from 12 to In Progress
- 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
- 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.
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...
- Status changed from Fix Under Review to In Progress
- Assignee changed from Sage Weil to John Wilkins
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.
- 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.
- Status changed from In Progress to 12
- Status changed from 12 to Resolved
Also available in: Atom
PDF