[zeromq-dev] Stable release downloads (was Re: CZMQ "stable" release versioning)

[Ewen McNeill]

On 25/04/16 21:51, Pieter Hintjens wrote:
> Yes, retiring the deprecated APIs and bumping the major version should
> go together.

It also seems timely to raise where these stable release downloads come 
from when a user downloads them.

http://zeromq.org/intro:get-the-software

links to download URLs like:

http://download.zeromq.org/zeromq-4.1.4.tar.gz

and download.zeromq.org is:

ewen at ashram:~$ host download.zeromq.org
download.zeromq.org is an alias for virtual.imatix.com.
virtual.imatix.com has address 95.142.169.98
virtual.imatix.com mail is handled by 10 mail-in.imatix.com.
ewen at ashram:~$

and virtual.imatix.com is an alternative name for a VM... that is paid 
for by iMatix (ie, by Pieter).

So we'll need to find another place to host these downloads.  Personally 
I'd like it if _all_ the existing downloads were moved to that new 
place, rather than just being abandoned (I've spent too much time last 
year/this year trying to track down old code that didn't get carried 
along with moves to want to cause that to happen again).  That would 
also let us potentially make download.zeromq.org point at that new 
location, and thus keep existing URLs working.

Currently there are 160 downloadable files on download.zeromq.org, 
taking up 194MB of files; so an average around 1.2MB each.  With 
presumably some of them being downloaded more than a trivial number of 
times.

Pieter and I briefly discussed using GitHub Releases:

https://help.github.com/articles/creating-releases/

along with a custom binary which was whatever tarball, binary, etc, had 
been built.  From what I could tell from a quick look this is plausible 
without cost (for an open source project), at least under 1GB total 
(https://help.github.com/articles/what-is-my-disk-quota/) and maybe 
larger if they're explicitly attached to releases 
(https://help.github.com/articles/distributing-large-binaries/) which 
then seem to get stored outside the git archive itself.

But (a) there's a "technical debt" of uploading 160 files (with 1-2 
files per release), and (b) there aren't even any tags on the 
zeromq/libzmq repository AFAICT, so there's also the technical debt of 
figuring out where all these files should "attach" (ie, what's the 
matching source).

I'm explicitly _not_ volunteering to spend the time figuring out where 
all these tags belong, and releases should be created/uploaded.[0]  But 
I can, eg, provide someone with a list of URLs to download all the files 
from download.zeromq.org if they were to volunteer to do this.

There's an API to automate some of it:

https://developer.github.com/v3/repos/releases/#create-a-release

but that also requires a git commit ID to attach each release/set of 
files to... which I suspect is the hard part to figure out.

Alternatively, other ideas for where to store the downloads that don't 
rely on iMatix/Pieter would be a good idea.  Before the next release is 
"cut".

Ewen

[0] My "software archaeology" time has been going into:

https://github.com/imatix-legacy/
https://imatix-legacy.github.io/

(there's still a couple of pieces to convert over to GitHub, but the 
imatix-legacy.github.io one is now close to replicating the early 2000 
iMatix website, with the source for everything at 
github.com/imatix-legacy/ in at least a "human reviewable" form.)