[Stk] New release and maintenance

[Stephen Sinclair]

On Tue, Aug 9, 2016 at 7:15 AM, Ariel Elkin <arielelkin at gmail.com> wrote:
> Hi Gary,
>
> Following what you've described I've taken a closer at the code, but I don't
> know what caused the discrepancy.
>
> The root of the problem is that the code tarball and the changelog are being
> duplicated on the CCRMA download page and on GitHub. This is evidently
> creating more problems than it's solving.
>
> I've explained why I believe the CCRMA download page
> (https://ccrma.stanford.edu/software/stk/download.html) is redundant, with
> all the development and releases happening on GitHub.
>
> So could we have the CCRMA download page simply link to the GitHub
> repository page? This would imply moving the changelog to a CHANGELOG file
> we'd add to the repo.
>
> If we agree to this, like I said, I'd be happy to take care of releases,
> which requires a bit more in-depth knowledge of git, and this kind of issue
> wouldn't happen again.
>

Respectfully, I disagree.  STK should remain associated with CCRMA and
McGill, and as such, offering a download of the tarball should be

1) not problematic

2) encourage users to use the tarball instead of the git repository
(which imho leads to problems when people try to use in-development
changes)

I think it's generally a good policy to have an "official" tarball somewhere.

I also disagree that this is the "root" of the problem.  The root of
the problem is that the tags got misplaced.  That needs to be fixed.
The version associated with the tarball releases should be tagged
correctly.  Hosting the distribution 100% on github would obviously
not fix this issue.

Release procedure is simple:

- update version number and commit
- git tag
- make dist (or manually make the tarball)
- upload resulting tarball.

That's it.  (Well, "make dist" depends on using automake, which
currently STK does not, but RtAudio and RtMidi do.  Otherwise, Gary is
perfectly capable of putting together the tarball the way he likes
it.)  I don't think this should be problematic to keep doing in the
future.  This issue of misplaced tags is just some kind of slip-up,
I'm not sure how it happened, but let's not blow it out of proportion.
The "upload resulting tarball" is not the problem here.  Something
happened at the "git tag" stage.  Fortunately, it is easily fixed.

Steve