Git-Windows download page still points to 2.16.2

[lll000111]

The download page still lists 2.16.2 as the binary, but the 2.17 (Windows) git binary version has been available for quite some time now:

[pedrorijo91]

@peff shouldn't the cron job check every night for new releases?

[pedrorijo91]

I ran the rake task locally (as described at https://github.com/git/git-scm.com/blob/master/ARCHITECTURE.md#heroku) and the latest win version is 2.17.0

on heroku we have as last run: Apr 19, 7:31 UTC

[lll000111]

https://git-scm.com/download/win still offers 2.16.2 :-)

[pedrorijo91]

Been looking at this today. The versions and downloads were in the database, but there was some problem.

The query being executed to get the download url is:

SELECT  "versions".* FROM "versions"  ORDER BY versions.vorder DESC LIMIT 1
  SQL (2.4ms)  SELECT  "downloads"."id" AS t0_r0, "downloads"."url" AS t0_r1, "downloads"."filename" AS t0_r2, "downloads"."platform" AS t0_r3, "downloads"."version_id" AS t0_r4, "downloads"."created_at" AS t0_r5, "downloads"."updated_at" AS t0_r6, "downloads"."release_date" AS t0_r7, "versions"."id" AS t1_r0, "versions"."name" AS t1_r1, "versions"."commit_sha" AS t1_r2, "versions"."tree_sha" AS t1_r3, "versions"."committed" AS t1_r4, "versions"."created_at" AS t1_r5, "versions"."updated_at" AS t1_r6, "versions"."vorder" AS t1_r7 FROM "downloads" LEFT OUTER JOIN "versions" ON "versions"."id" = "downloads"."version_id" WHERE (platform='mac')  ORDER BY versions.vorder DESC, downloads.release_date DESC LIMIT 1

so probably some of the records had some corrupt/missing data that lead to the LEFT OUTER JOIN failing for the 2.17 version (which lead to the latest version to be the 2.16.2).

I'm not proud of the solution, but the fastest way was to delete the downloads and versions table content and run the rake downloads task again.

everything seems to be working now @lll000111

[peff]

I think I've seen some weirdness before if the manpage database gets manipulated behind the scenes, due to the join between the versions and downloads table. So if you blow away the versions table and then rake preindex to rebuild all of the versions, you have to also blow away the downloads table. I don't recall having done any funky manipulation of the versions table recently, but it may have been a lurking problem (I'm also not sure if we could run into problems if the downloads task runs before the preindex task picks up the new version).

Since things seem to be fixed now, I think we can count this as an anomaly and keep our eyes on it for the future. Thanks for dealing with it, @pedrorijo91.