and noticed that some of the dates didn't quite seem right.
I would suggest:
Closing the 1.3.7, 1.4.3, 1.5.9 milestones. There are no outstanding
tickets and it seems really clear there will be no more releases on
those branches, even if an egregious security bug arose.
Maybe closing 2.0.8, after moving tickets forward to 2.2.2. It's not
clear if these are ok on 2.2, and need fixing on 2.0.8. It seems
fairly clear there won't be any more 2.0.x releases, but I'm not
Similarly for 2.1.9.
if 2.1 and 2.0 are kept, set dates ahead so that 2.2 sorts first, then
2.1, then 2.0.
Move the "management 2.0" date to about 5 years in the future, so it's
ahead of "postgis future" but behind all actual planned releases.
Figure out what "Postgis Future" vs "Postgis GEOG", etc. means and
probably merge them. It seems like these aren't really distinct and
are just tickets not planned for any release. The components of
tickets and the milestone names don't seem entirely correlated..
Having a date 10 years out for "future" makes sense to me, as a place
to park unplanned work.
So we'd then have milestones in order:
2.2.2 (with a realistic or at least plausible planned next release
2.1.x (with a realistic date if planned, or if it's just there in case
there is a serious bugfix, maybe 2years out)
2.0.x (a month after 2.1.x)
mananagement 2.0: maybe 9 years out
postgis future: 10 years out
and that's it. Presumably 2.1.x would have only tickets that are known
not to apply to 2.2 (fixed, or in 2.1-specific code), and I would think
most of those would get moved or closed.
This is not a big deal, but it would be pretty easy to clean up and then
roadmap would be easier to follow, 1 page instead of 2+.