Releases should be shown in descending order

[bgentry]

heroku releases shows most recent releases first. I think this is usually what the user wants. We should default to the most recent releases.

We should also limit the number of releases requested from the API, as this can be a big list for active apps. What's a good default? For some reason heroku releases defaults to 14, which is an odd default imo.

It might also make sense to provide the user with an option to request more or fewer releases (i.e. -n 100).

This becomes possible once #74 is merged.

[kr]

Whatever default we pick, it'll be wrong. Better to just show all of them. This is also what ls does, even when listing thousands of files.

If we did truncate the list by default, then, as you mention, we'd have to add a special-purpose option such as -n just to increase the result set. But there's already a way to show just the last few releases:

$ hk releases|tail
d24f933  maciek@he…  Sep 16 17:05  155  Deploy d24f933
aa54178  maciek@he…  Sep 17 15:40  156  Deploy aa54178
3040ce2  maciek@he…  Sep 17 16:53  157  Deploy 3040ce2
940fb82  maciek@he…  Sep 17 18:04  158  Deploy 940fb82
         maciek@he…  Sep 17 18:47  159  Add papertrail:fixa add-on
97522dc  maciek@he…  Sep 17 18:58  160  Deploy 97522dc
3277a37  maciek@he…  Sep 18 14:02  161  Deploy 3277a37
12d2f17  maciek@he…  Sep 18 16:29  162  Deploy 12d2f17
2699332  maciek@he…  Sep 23 03:21  163  Deploy 2699332
e810fef  maciek@he…  Sep 25 04:03  164  Deploy e810fef

This keeps the interface simple and keeps the user in control. I shouldn't have to learn millions of configuration options to get the data I need. Software should just work. Avoiding avoidable flags is part of how we can achieve that.

[bgentry]

@kr one thing to note, we're not currently getting all of the releases. We're just not specifying a limit, which gives us the default limit of 200: https://devcenter.heroku.com/articles/platform-api-reference#ranges

I feel like users will be surprised and confused the first time they run hk releases on a heavily-used app and see hundreds of releases scroll by. How often to people really want to see more than the last few?

[kr]

Were you surprised and confused the first time you typed ls in a directory with hundreds of files? Or when you typed cat on a file with hundreds of lines? You may be right if we're only talking about people who are accustomed to the behavior of the old heroku releases command, but only because that's what they're used to, not because it's any less surprising. You can't be better without being different.

It's nice to optimize for the common case and make that the easy thing to do, but we have to balance that against adding complexity to the interface. Hk is going to have a large surface area no matter what, so I want to take every chance we can to keep things narrow and focused.

[bgentry]

@kr if we don't make an explicit choice on the limit, we're going to get the default pagination size of 200. Unless we want to build in support for paginated API actions (looping until we've grabbed them all). If we did that, I'd be concerned about churning through users' API rate limits, and the slowness of getting more information than necessary from the API.

[kr]

The max page size is 1000.

Most apps* will never go past more than one page of releases. Those that do will get results in batches of 1000, which seems plenty fast enough. (And not many api calls – 3 api calls for an app with 3000 releases? seems ok to me.)

If the server is too slow, we should fix that by making the server faster, not by complicating our public interface as a hack to work around problems in the api. If too much data transfer is actually a problem, there are still options, e.g. client side caching. (But those are performance optimizations, not worth doing until we see real performance problems.)

What else can we think of? Are there other possible solutions? Ways to satisfy all (or at least more) of the design goals: a simple interface, good performance, unsurprising behavior, etc?

* Search dataclips for the arithmetic mean number of releases per app. (I tried getting median and max but the queries took too long.)