On Mon, Jul 11, 2016 at 09:57:24AM -0400, we recorded a bogon-computron collision of the <[email protected]> flavor, containing: > On Sat, 9 Jul 2016 13:48:29 -0600 > Tom Russo <[email protected]> wrote: > > Github doesn't work like this. A release on github is just a tagged > > state of the git repo, and when you ask to download it, it bundles up > > that SHA-1 into a tarball/zipfile/whatever. You can't have it be a > > processed version of the sources, like sourceforge does. > > Actually, you can. > > Releases are created automatically by github when a tag is pushed to > github. The release tars up the repository at that tag, but then you > can edit the release page in github (describing the release in more > detail than in the commit message with markup, if desired), > and attaching arbitrary files, including binaries, to the release.
Yeah, I saw that feature. But the process of running bootstrap actually populates the source tree with extra files and directories. This seems different to me than simply attaching extra files to the release. At the very least, it seems a lot more trouble. > See, for example, an executable jar we've uploaded to a release in another > project I'm working on. > https://github.com/kurator-org/kurator-akka/releases/tag/v0.3 The jar you've attached to your release appears separate from the source tarball. In order to be useful, the bootstrapped files would actually need to live inside that source tarball. We could, of course, attach a separate tarball of just the autoconf output, but then is that much more helpful than telling users "run bootstrap.sh" after unpacking? -- Tom Russo KM5VY SAR502 DM64ux http://www.swcp.com/~russo/ Tijeras, NM QRPL#1592 K2#398 SOC#236 http://kevan.org/brain.cgi?DDTNM echo "prpv_a'rfg_cnf_har_cvcr" | sed -e 's/_/ /g' | tr [a-m][n-z] [n-z][a-m] _______________________________________________ Xastir-dev mailing list [email protected] http://xastir.org/mailman/listinfo/xastir-dev
