[Xastir-dev] Releases on github vs. releases on SourceForge

Paul J. Morris mole at morris.net
Mon Jul 11 08:39:54 PDT 2016


On Mon, 11 Jul 2016 09:25:37 -0600
Tom Russo <russo at bogodyn.org> wrote:
> On Mon, Jul 11, 2016 at 09:57:24AM -0400, we recorded a
> bogon-computron collision of the <mole at morris.net> flavor, containing:
> > On Sat, 9 Jul 2016 13:48:29 -0600
> > Tom Russo <russo at 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
mole at morris.net  AA3SD  PGP public key available


More information about the Xastir-dev mailing list