Huh, if all the files of the repository at that tag aren't the "source code" of that release what is?
Do your projects not have a README telling people how to build? Are you targeting a nontechnical or beginner audience?
Really the main purpose of source distributions is for packagers. Especially when you're creating pkgbuild scripts like for archlinux's AUR or gentoo or slackbuilds or macports or BSD, all the tools needed to build the source code become build-time dependencies for your package, which is annoying for people installing it.
[1] http://source.winehq.org/git/wine.git/blob/0f8a0fd4002f9d5d1...
It's more likely than you think.
If you use something other than cmake or autotools, you're going to end up making the lives of packagers more difficult. If they have to change anything, as they usually do, they're going to have to know how the build system works, and they dont necessarily want to deal with whatever new-fangled build system you're using.
Usually projects using cmake distribute their source code with cmake build scripts because they're taking advantage of cmake's cross plaform features, and cmake generates different source distributions for different platforms. But this does place a burden on the user to have cmake installed. There's a good argument to be made that that's no longer much of a burden, after all, it's just one package manager invocation away. But you have to think about who's downloading a source distribution (as opposed to binaries or checking out the repository). They're people who are compiling from source for esoteric platforms, perhaps and embedded system, where a cmake package might not already exist. They're people like me who are writing their own pkgbuild script because they like to keep their system well organized and not have too many useless packages (like cmake) lying around. They are people creating a new linux distribution who haven't yet packaged cmake but want to package your software.
And in terms of software design, cmake isn't very good, at least in the eyes of many people writing unix systems software, which as far as mature open source software projects written in C/C++ go, is a lot. Don't get me wrong, cmake certainly has the cross platform advantage, and if you're making software that you want to compile on windows, you'd be remiss to not at least seriously look into using cmake (not that it's the only option, you could also opt to lean on cross-compiliation from a unix platform to windows, distributing binaries only, or requiring users to install cygwin, which isn't worse than having to install visual studio if you don't already use it).
But if you're not taking advantage of the cross-platform features, I'd say cmake is pretty awful. Precisely because it's cross-platform, cmake rejects the typical design principles of unix software, instead offering a monolithic build system that requires special scripts to be written for any different tools you want to use, or even any complicated dependencies (for example: SDL). This is necessary because cmake needs to establish a consistent internal interface that can work for both the windows and unix tools. As a result, everyone has to learn how to use the monolithic cmake system from the ground up, and those skills won't be useful for anything else.
In contrast, autotools, known for having a high learning curve, is really not that bad for people who already know unix. If you understand how to use a unix system, you can figure out autotools faster than you can cmake. And you can really know it, to the extent that you feel confident diving in and messing with its defaults, much sooner than you would with cmake.
But of course, ease of learning isn't the only factor autotools integrates with external tools using their standard interface while cmake demands you essentially write a wrapper for them. Autotools is simply more flexible.
I don't like autotools, for the record, but given the options available, I'd probably choose it over any other build system in almost all the places it's used currently and more.
I've been using unix since 1992 and find the entire autotools suite to be almost incomprehensible. The low point was in 2014 when I was trying to compile a package that intentionally did not ship a configure file and made the user explicitly call autoconf. This would have been ok except that in the 3 or so years between when the code was released and I was trying to build it, autotools made some backward-incompatible changes and autoconf/automake errored out, with no indication of how to fix those. Eventually I just gave up and used a different package.
Conversely, when I started using cmake (motivated by clion using it as a build system) I was able to get it up and running basically immediately, and 12 months later I appear to have become the cmake guru for my company.
At the risk of having to admit I've had my share of bad experiences with autotools, don't ever do that. That is a big sign with flashing lights and sirens, saying that you should put that package down and leave it alone. Because...
"This would have been ok except that in the 3 or so years between when the code was released and I was trying to build it, autotools made some backward-incompatible changes and autoconf/automake errored out, with no indication of how to fix those."
The version of autotools someone was using when they wrote the scripts is very closely tied to the scripts. It's not at all a good idea to use a different version of the autotools.
And indeed, the exact issue the OP is complaining about is how the zipfile automatically created by GitHub has NOT had autotools run on it yet, and the maintainer cannot even manually overwrite that file!
For example: for autotools based build systems you want to run autoconf and automake to generate the Makefile.in and configure scripts.
The tag link points to the tree (in Github's file browser UI) for the release, and the commit ID link points to the specific commit for that tag (in Github's diff UI).
Trouble is, this isn't very discoverable, given that those two links aren't styled as links-- they're the same font and color as is used for the subheading with date and commits since, which aren't clickable elements.
It isn't the case for all projects, but for some there are some pre-build steps that the majority of people who want to install and use the project don't have or even know about. The project can put up the source after those steps are done, and the downloader does the final source building and installation with ease.
As an end user looking at the release page, you can't tell the difference between the easy way (the pre-processed source that will work well for you) and the hard way (you'll need to install and invoke several tools for no real benefit).
The underlying problem is that Github make it really easy for people to end up with the hard way, and not the intended easy way. This benefits no-one. I have no problem with them making the repository files available - I just want them to stop confusing people who go to a release page.
Many small projects don't have a releases page. The download zip is just a way of quickly getting the source code for such projects.
To be honest, I wasn't trying to start an argument. I was just pointing out that I like having a "download zip" button.
The specific top level complaint is about the releases page when visited by a human who would have the goal of building and installing the software release. There the "Source Code" link is misleading if the maintainer has a release file that is the expected one for building and installing the software.
I fall for this everytime I go to use that link.
The people who is it once every week or two, like me, get lost each time. It's always a hunt when I want to figure out how to do something, even if I know I've done it before.
A few examples for me:
- From a "pull request / files" view like this (https://github.com/google/protobuf/pull/1191/files), when I want to view a whole file, I always want to click on the filename. But the filename isn't a link: you have to look at the right side and click the button that is generically named "View" (View what?).
- At the top level of a repo (ie https://github.com/google/protobuf), you can click "X commits" to view the list of commits. But when you go into a subdirectory (ie. https://github.com/google/protobuf/tree/master/benchmarks) the "commits" link disappears, and to view the commits in that directory you have to look on the right side instead for a button that says "History".
- continuing from my last point, if you view an individual file, (ie. https://github.com/google/protobuf/blob/master/benchmarks/Pr...), the "History" link is in yet another place! So between the top level, a subdirectory, and a file, the link to view history is in three different places. I don't follow these links quite often enough that it becomes automatic, so it slows me down every time.
In one project I went as far as making a "releases" branch, and actually putting the "make dist" output there, in full, and tagging that instead of the master branch. This was a pretty good compromise, since the github download link now points at the actual release tarball, and you can easily see from `gitk` which commit from the development branch each releases branches from.
However, it's annoying not to be able to use tags as a way of navigating the development branch, and since I wasn't the one officially putting together final releases, eventually it was found that this was just too complicated to keep doing for each release. And it's just a dumb trick to satisfy github's weird releases interface anyway, so I couldn't justify the complexity.
That said, I am also cognizant that "checkbox overload" is a real thing, so merely "for your consideration"
"Source Code" has two meanings. One is the preferred form of contributing to the project. The other is the preferred form for building and installing it on a system. Sometimes they are the same. However I argue someone going to a release page is more interested in the latter, and the former is confusion.
I'd suggest making your UI reflect the page visitor's goals. "Repository Archive" is better wording, but still not that good.
They unhelpfully add a "Source Code" link, which would be great if that is what it was. Instead it is actually just a zip file of the repository at that tag. But the repository is in a maintainer state, so the "Source Code" isn't useful to an end user because various tools need to be run (eg building help, automake/autoconf, dependencies). The people mislead by Github due to this "Source Code" contact me, not github.
Every six months for several years, I send the email explaining how this doesn't serve anyone's interest, how it hurts, and that I am happy with any solution (eg don't auto add, change the name to make it clear, be able to label an existing file as the "Source Code" etc). I get the usual response of understanding and sympathy, and vague suggestion that it may be addressed. Three years and counting ...