[Stk] proposal for stk git repository layout

[Stephen Sinclair]

On Tue, Oct 1, 2013 at 12:08 AM, Ariel Elkin <arielelkin at gmail.com> wrote:
> Nice work Steve!

Thanks!

> It's a bit overkill to maintain a whole git branch ("releases") just for the purpose of providing STK users an easy way to download release tarballs.

How is it "overkill"?

I would agree with just uploading .tar.gz files somewhere like has
already been done in the past, but I was just trying to find a
solution to use github for hosting them.. this seems to work fine.
It's really not that complex, and unless you are the one tagging
releases, you don't have to worry about it.

> I think one single "master" branch suffices: carry out all the development work on it, create git tags on it to mark releases, and then direct end-users to the repository's Releases page that GitHub generates:
> https://github.com/radarsat1/stk/releases
>
> Thus, end-users will only download the stable releases and not the latest upstream commits.

This seems to be working fine already.  The link you provide above
contains downloads for all previous STK tarballs.


> If you take a closer look at the Releases workflow that's provided by GitHub, you might find how it can easily supersede the "releases" branch:
> https://github.com/blog/1547-release-your-software

I don't see how manually dragging and dropping files into a web page
is easier than just merging them into the "releases" branch -- the
latter can be automated with a script.


> Crucially for us, this Releases workflow enables us to attach assets to the source code release: these could be RtAudio and RtMidi, the empty Debug and Releases folders, and the makefiles?

This seems to work fine with the "releases" branch, what further
benefit does using the github Releases feature bring?

In addition, sticking all releases in the git repo directly instead of
using extra github features makes us less dependent on github and
easier to move everything to another provider if it ever becomes
necessary.

Steve