Anyone have thoughts on the version dropdown in th...
# development
b
Anyone have thoughts on the version dropdown in the new docs site? I think this might be the last little bit that I want to plug in before I start getting it ready for primetime? Specifically: • How many versions should be shown? ◦ Obviously the "supported" one, so 2.18.x. What about 2.17.x? 2.19.x? 2.20.x? • Should the version for
main
be shown? ◦ E.g. 2.20.x? Right now I'm toying with only showing: • The prerelease version (e.g. 2.19.x) • The release version (e.g. 2.18.x) The
main
docs exist (e.g. 2.20.x) but not accessible from the dropdown. Similarly, the dropdown has a link for "All Versions" pointing to all the released versions (e.g. "where's 2.14.x docs?)
h
I think one before the current release version as well?
Or even two?
b
One before would mean 2.18 and 2.17. Two would include 2.16. I don't like doing two because 2.16.x is "dead". Even 2.17 is (we no longer have a milestone for it) but I get keeping it around, docs-wise
c
it may be dead to us, but I imagine it’ll still be in use for some time still.. not everyone does upgrades in a consistently timely manner, and having the docs readily available for their version is easy enough for us, right?
I think it could make sense to present the docs for stable versions that’s been released in the past 12 months, to have a timeline rather than a fixed number of versions..
b
That would be much more difficult 😅 Right now we just trim an array of versions. That would involve correlating those versions to dates. We could approximate though
👍 1
c
lol- yea I saw that reply coming, and I’m perfectly fine with just picking a set of versions now, and if we want to get fancy looking at release dates we can add that later 😉
looking at release dates, 2.15.0 was released in Feb this year… but as you say, having 2.15.0 - 2.19.0 is quite a few versions… and if the full list is but a click away, I’m no longer sure how many we want to show up front in the drop down.. 🤷
b
My own opinion is that 20 is too many, 2 might be too few. So as long as we land a number between those 😂
1
c
Well I think 12 months back is a reasonable timeframe, and that lands on 2.15.0 (or even 2.14 if we count the patch releases)
b
So roughly 5-ish versions? I can dig it. let's see what it looks like
👍 3
OK second question: First one? Second one? Something else?
c
I like the construction sign.. but that feels like for a dev release, so if
main
where on there. So +1 for using “(stabilizing)” or similar. I think I’m in favour of not marking the oldest one in any particular way..?
b
main
would be 2.20.x
👍 1
(and I was thinking test tube emoji for that) 🧪
c
I see the logic, find the 🚧 more universally as the “under construction” sign, but don’t have a strong opinion in either direction.. other than that for release candidates it feels like they’ve ought to have passed the “construction phase”…
b
I'm open to ideas. The only challenge is we really can't use HTML there, just text (I mean we can but it's annoying and involved)
c
I think less is more here.. so defaulting to the latest stable, and marking any prerelease or dev versions if present but leaving the others bare…?
b
I marked all the sunset releases as such to kinda denote that. In the current site they say "deprecated"
h
let's use clear words, not unclear emoji
b
Thoughts on "sunset" vs "deprecated" vs "something else"?
h
deprecated sounds good to me, and consistent with our other uses of that term
b
It does take up some real-estate... Let's try ir
c
“eol” is short, but maybe less clear…
b
OK I kinda like the word choice. Thanks for playing 🙂
👏 1