Download Count Per Package, not just Package Version

Coordinator
Dec 3, 2010 at 7:44 PM

Hi All,

I noticed that the current implementation of download count is per individual package version and not per package. Conceptually, when I think of a package like "NHibernate", i want to know the download count for NHibernate in total, not just a specific version. Ideally, I'd like to know both numbers.

You can see how RubyGems.org does this: http://rubygems.org/gems/rack

They show the total download count as well as the download count for specific version. I think the same thing should apply for ratings as well.

Is this something that's on the roadmap for v1? The NuGet package dialog is expecting the download count to be consistent when grouping packages by ID, so we need the package download count as a sort and not a package version download count. Likewise with average rating.

Coordinator
Dec 6, 2010 at 3:43 PM

We hadn't thought about this issue previously, but it makes sense. This seems like it should be fairly simple to do, so we'll try to work it in soon. I suppose this means that every item on the feed will have to carry 4 properties instead of 2: DownloadCount, VersionDownloadCount, AverageRating, VersionAverageRating (or something like that - I'm open to suggestions on the property names). Is that what you're thinking?

Coordinator
Dec 6, 2010 at 4:57 PM

I was thinking:

· DownloadCount

· TotalDownloadCount

· AverageRating

· TotalAverageRating

AverageRating and DownloadCount would apply to the current record (aka current package version), while Total is the aggregate across all package versions of the same package id. Make sense?

Phil

Coordinator
Dec 6, 2010 at 5:01 PM

Okay, makes sense. Those are probably better names. Adding a story for this to our board now ...

Developer
Dec 6, 2010 at 5:17 PM

Hmmm, TotalAverageRating sounds wrong to me, as it really isn't a 'total' in any sense of the term.  Maybe 'Overall' is clearer (for both).  Also, I'd drop the word Average, which is the assumed semantic when talking about rating.  So we could have:

  • DownloadCount: we already have this today
  • OverallDownloadCount
  • Rating: we already have this today
  • OverallRating

One thing this leaves our is our current concept of 'RatingsCount', so technically we would need both

  • RatingsCount: we already have this today. Note that it's called RatingCount (no 's') in the GalleryFeed so as a side note that's a small mismatch that needs ironing out
  • OverallRatingsCount

Man, that's a lot of fields! :)

Coordinator
Dec 6, 2010 at 6:25 PM

We can go with those names. I agree those are a little better. And I forgot about the count, so you're right, we need another field for that too.

Developer
Dec 7, 2010 at 11:33 PM

Note that we ended up going with the reverse naming, where we use the current field names to semantically mean the 'Overall', and come up with new names for the per-version.

This is captured in http://galleryserver.codeplex.com/workitem/26 and http://galleryserver.codeplex.com/workitem/27.

Sorry for the indecision. but we realized that since we can no longer change our 1.0 bits and they need to be using the overall numbers, this was the best approach.