[zeromq-dev] ZeroMQ 4.2 release, planning

[Ewen McNeill]

On 4/05/16 8:21, Luca Boccassi wrote:
> But most importantly, the tarball will ship stuff that shouldn't be
> shipped, which is a huge problem for distribution packagers.

To echo this: if there are things in the upstream tarball that they 
shouldn't ship, they have to undo things from the upstream tarball, 
rather than just having some patches adding to it.  In the worst case 
(licensing problems) they have to build a "replacement upstream" 
tarball, which is just painful for everyone.

Personally I think it should be possible for anyone to "make a 
distribution file" (eg, for their own use), and that the tooling to do 
that should be in the repository.  It stops that being magic special 
sauce that is known only to a few people.  Which means "make dist" 
should continue to exist.  (And it sounds like it's been fixed to work, 
which IMHO is the solution to anything that "almost but not quite works" 
:-) )

As for GitHub releases, AFAICT:
- if you tag a release commit, I think you get automagic tar.gz/zip 
releases of what is in the git trees at that commit, which is probably 
useful for distros.  (And some distro systems, eg MacPorts, can also 
clone git as of a release tag and build from that, so it is multi-use.)

- in addition to that, ie, with the tagged release commit, you can 
_also_ upload "binary artefacts" (eg, your own tarballs, or binaries) 
which may have some of the generated bits pre-generated (which removes 
dependencies on some auto tooling/knowledge).  These need to be attached 
to the commit.  AFAICT these bits then get served from Amazon S3 at present.

The combination of these two might give ZeroMQ projects the best of both 
worlds (eg, providing the names didn't conflict).  A "tarball of git" 
_and_ a "ready to build, just run make" version as well, and people 
could get what they wanted.  There's an API for uploading these binary 
artefacts, so it could potentially even come from the CI system (eg, 
Kevin's work with Travis), based on seeing a release tag added.

All of the above depends on having git tags for the release commits.

Also FWIW, Doron and I have been talking about using Amazon S3 
separately to host the existing downloads.zeromq.org tarballs (ie, 
uploaded as binary artefacts).  I think the main thing we'd need is some 
way to translate the (long) S3 URLs into something friendly people can 
find, hosted somewhere.  For which my thought was maybe using 
https://zeromq.github.io/libzmq/ (ie, the gh-pages branch in the 
repository), since that doesn't currently seem to be used, and could be 
auto-built given a list of S3 URLs and the tarballs that were uploaded.

I'd like to get _all_ of downloads.zeromq.org hosted somewhere else this 
month (May 2016) _and_ to ensure that everything that's there (160 
files) are still downloadable (just with new URLs) for posterity.

Ewen

PS: Someone adding release commit tags to the libzmq, etc history for 
all previous releases (ie, as of that commit) would be great.  Or at 
least the recent ones.  But I think that would be a manual process to 
find them (eg, reviewing "git log" looking for changelog updates or 
similar).