On Tue, Nov 6, 2018 at 12:29 PM Nathan Cutler <ncutler@xxxxxxx> wrote: > > >> 1. The releases schedule page has been updated to be driven by a yaml > >> file so we can have a machine readable db of release information. The > >> format of the page is little different but can easily be tweaked: > >> > >> http://docs.ceph.com/ceph-prs/24452/releases/schedule/ > > When I compare this with what we currently have at > > http://docs.ceph.com/docs/master/releases/schedule/ > > a few things jump out at me: > > 1. information on which versions are EOL is missing in the PR version (I > understand that particularly bright readers will make the mental leap > and conclude that versions not listed as "current" must be EOL, but I > miss having the acronym "EOL" explicitly appear under the headings > because that does help drive the point home to folks when necessary) > 2. information on when the EOLed versions were retired is gone These two issues are very easy to address. The data is there, it's just a UI update. > 3. the PR version has multiple rows per month, while in the master > version there is only a single row per month (i.e. months with multiple > releases get merged into a single row) Yeh, this bugged me too! This is certainly possible, but it's a little harder. We are building the table programmatically, and I haven't gone deep enough on the table API in docutils to figure out how to do cell / column merging. > How difficult would it be to address these gripes? In general, I like > the idea of generating the table from a yaml source file, but it seems > like we are sacrificing information value to achieve this? The driving force behind having a machine readable source file is that it is going to be used to create dynamic version switching UI on the docs, and current is used to drive the UI that warns about old unsupported docs. Building the table from this data was simply an effort to avoid requiring updates to do locations. I'll add (1) and (2) above to the list of UI updates to go in soon. I'm not sure how much work (3) will be.
