Include a cadence for releases

[daveverwer]

How about a bit of extra information at the end of the releases clause:

Currently:

• In development for 5 years, with 1,448 commits and 81 releases.

How about including a cadence, like this:

• In development for 5 years, with 1,448 commits and 81 releases. The average time between releases is approximately 10 days.

[daveverwer]

... continued from the good discussion about this in #438

I want to know if a package is no longer being maintained (not super clear currently)

One thing that's in the works is to try and give every package a grade, not just a quality grade but a maintenance grade. I haven't come up with the exact metrics for this yet but it aims to make that question completely glanceable.

It's not like we're trying to predict the future

Yep, I agree there. My original thought around this idea was to give an indication generally how active a package was. Don't take this as any indication on the final design, but I just mocked up the start of something a bit richer:

18 months back in time from today. Showing releases as lines, and the version number. Where two releases are very close together it's showing only the later release. This would not be trivial to implement but might be worth thinking about.

On mobile, we could split the bar into three sets of 6 months, the dates on the bar are deliberately positioned so they would line up vertically in a mobile layout.

[Sherlouk]

I think that's definitely an interesting idea and I'm more in favour of visual ways of showing information because as you say they were more glanceable.

It could be good if we could build up the graph with some more data potentially with different colours to give it some depth (a lighter grey for system/contextual events as opposed to the dark grey/black for package events).

Examples:

• If the package supports iOS, we could show major iOS releases?
• Major swift releases?

Of course we need to not make it super dense but it would be helpful where we only have dates every 6 months to give context to where these releases were.

[mattpolzin]

Showing releases as lines, and the version number.

This (almost exactly as mocked) is what my mind went to when I first read the idea to display release cadence information.

Another place my mind went would be to get even more abstract and just give the user a sense for whether the package is currently in a certain part of its growth/maintenance “curve” by graphing release frequency as a line of releases per {time unit} without scale. The user would see that the packages release cadence is either currently stable or not as well as whether it recently rose or dipped a large amount at a glance.

[Sherlouk]

Does this design still fit into your masterplan Dave, or have you changed your mind since the package page redesign?