MAINT: appveyor conda.org uploads

[tylerjereddy]

• turn on conda.org uploads for appveyor CI;
  we never did weekly uploads for Appveyor/Windows
  wheels so just turn on for merge events

• hopefully this will restrict to merges and not
  successful PR branch runs by virtue of secret variable
  availability only within the repo itself (so most PRs
  should be opened from forks where possible)

[tylerjereddy]

CI finally looks good now--let's see if the appveyor staging uploads happen after a merge event.

[mattip]

The weekly wheels have a git hash in their name, which does not indicate chronological order. The old multiwheel uploaded added the date to allow ordering the uploads.

In numpy-wheels I added a rename function to add the date in the weekly uploads. That way pip will take the latest. It changes scipy-1.5.0.dev0+6f0b508-cp38-cp38-macosx_10_9_x86_64.whl into ` scipy-1.5.0.dev0+20200515101522_6f0b508-cp38-cp38-macosx_10_9_x86_64.whl.

The staging wheels do not need that, since they do not have a git-commit hash in their name.

[tylerjereddy]

The weekly wheels have a git hash in their name, which does not indicate chronological order. The old multiwheel uploaded added the date to allow ordering the uploads.

The conda.org site has a sorting column you can click based on upload timestamp. Not saying I'm against adding a datestamp to the weekly Travis uploads for SciPy though. May depend on how other projects consume them I guess.

Will pip check the timestamp metadata on binaries if we don't change the filenames?

The staging wheels do not need that, since they do not have a git-commit hash in their name.

Ours do have a git commit hash in their name, until the release proper. So on a merge to master the staging upload area is populated with the dev version and hash. On a release feature branch the hash would presumably be excluded to give a pure "release version."

Something is going to go wrong for the next release attempt, I can feel it... :)

[tylerjereddy]

So, for staging uploads:

1. for final releases, yes should only have version number and are sorted that way by pip I guess
2. otherwise, the staging area basically just contains "junk" from merges for debugging/the release manager, so the hashes without dates are probably fine there

[mattip]

MacPython/numpy-wheels#84 was motivated by pandas-dev/pandas#33968. The rackcdn locations do have a date http://66ce22ef0bf26a5e2cca-4ffdece11fd3f72855e4665bc61c7445.r49.cf2.rackcdn.com/, and https://7933911d6844c6c53a7d-47bd50c35cd79bd838daf386af554a83.ssl.cf2.rackcdn.com/.

[tylerjereddy]

I see, I guess that's an informal indication that pip may not be automagically checking timestamps.