Expanding timeline #46

One solution that would improve things a bit is to make the version bars 1/3 of their current thickness and make the version labels appear only when hovering over the bars.

It looks like this is what we've got to play with:

http://visjs.org/docs/timeline/
http://visjs.org/timeline_examples.html

Maybe another approach is to change what the timeline is meant to convey? If the timeline only stated when 2.7 support reaches EOL for a project and when Python 3-only releases start then that would cut down on the number of bars. And if you didn't stack them but instead inlined the markers then that should mostly compress the timeline to only a handful of lines (possibly to 2).

The problem with the timeline is that it lists release schedules. But not all projects have release schedules. Really, you only need one timeline, with markers for each project for when they plan to drop support (maybe multiple markers for projects that distinguish full support from bugfix support). The marker text can contain version numbers if they are available (and if they don't take up too much space).

We can also implement some kind of popover for each project that gives a short plain text description of their plan.

We could also keep the existing version lengths timeline for CPython only. I think it's useful to show how long CPython versions, especially 2.7, have been around. But it makes less sense to show this for the projects.

with markers for each project for when they plan to drop support

Maybe two markers: one when they release a version no longer compatible with Python 2, and one when they drop support for the last version that supported Python 2 (for some projects this is different).

But yeah, I agree that having the whole release schedules may be overkill, or could be hidden by default and shown if the user clicks.

That's what I mean by full support vs. bugfix support. Not all projects provide support for older releases (SymPy certainly doesn't).