On Mon, 11 Jul 2016 09:25:37 -0600 Tom Russo <ru...@bogodyn.org> wrote: > On Mon, Jul 11, 2016 at 09:57:24AM -0400, we recorded a > bogon-computron collision of the <m...@morris.net> flavor, containing: > > On Sat, 9 Jul 2016 13:48:29 -0600 > > Tom Russo <ru...@bogodyn.org> 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.
Ah, I'm misunderstanding the problem - it isn't that you'd like a place to put compiled executable artifacts, it is that you'd like the release source archive to include the artifacts created by running boostrap.sh. > > > 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? A way to accomplish this would be to branch, run boostrap.sh, commit the artifacts it creates, then tag the commit that includes the artifacts and push the tag to github: (1) git branch release_x_prep, checkout release_x_prep (2) edit gitignore files so that artifacts created by boostrap.sh won't be ignored. (3) sh boostrap.sh (4) git add/commit (5) git tag release_x release_x_prep, git push --tags Development could continue on a master branch that doesn't have the generated artifacts committed. -Paul -- Paul J. Morris Biodiversity Informatics Manager Museum of Comparative Zoölogy, Harvard University m...@morris.net AA3SD PGP public key available _______________________________________________ Xastir-dev mailing list Xastir-dev@lists.xastir.org http://xastir.org/mailman/listinfo/xastir-dev