[Stk] New release and maintenance

Stephen Sinclair radarsat1 at gmail.com
Mon Aug 8 09:41:48 PDT 2016


It looks to me like the release tags got moved or were placed wrong
somehow.. At least they don't seem to be on the release commits.  e.g.
4.5.1 appears on a commit named "Rename SKINI.msg..." but much later
in the history there is a commit called "Lots of documentation updates
in advance of new release 4.5.1"

I don't know how it happened, but we should put them back to where
they go.  It can be done using "git tag -d" to delete the tags and
"git tag" on the correct commits and then "git push --force --tags".
Do you know off-hand which commits should be tagged 4.5.1 and 4.5.2?

Steve


On Mon, Aug 8, 2016 at 12:09 PM, Gary Scavone <gary at ccrma.stanford.edu> wrote:
> Hi Ariel,
>
> Something is very strange.  I made a new release (4.5.1) of STK in 22
> February 2016. My process (similar to what I have done for RtAudio and
> RtMidi) should have been to first create a release in github and then upload
> that to the CCRMA site (I don’t maintain two separate versions).  If you
> look at what the release notes say, they are the same.  But for some reason,
> the date on the release in github says 2 May 2014!!  And it looks like you
> made a release (4.5.2) on 12 May 2014.  That is simply weird.
>
> To be honest, I don’t use git enough to easily (quickly) go back and figure
> out what happened but something got messed up in the recent past.  Why does
> it show you making a release 4.5.2?
>
> Stephen, do you have any insight on this?
>
> Regards,
>
> —gary
>
> On Aug 8, 2016, at 6:34 AM, Ariel Elkin <arielelkin at gmail.com> wrote:
>
> Hi Gary,
>
> Then it looks like there might be a discrepancy in the STK's distribution
> channels...
>
> On the CCRMA website, the current release is 4.5.1 and dates from February
> 2016
> https://ccrma.stanford.edu/software/stk/download.html
>
> On GitHub, the current release is 4.5.2 and is actually two years old:
> https://github.com/thestk/stk/releases
>
> Messy. We're forking ourselves. Must be be tidied up.
>
> Can we agree that there can only be one and only one canonical version of
> the STK? User should always legitimately assume that all distribution
> channels serve exactly the same copy of the software.
>
> The first thing we should do is figure out the differences between the
> codebase on the CCRMA website and the codebase on GitHub:
>
> Download both:
> https://github.com/thestk/stk/archive/master.zip
> http://ccrma.stanford.edu/software/stk/release/stk-4.5.1.tar.gz
>
> Unzip them, then run:
> $opendiff ~/Downloads/stk-master ~/Downloads/stk-4.5.1
>
> you'll notice that the delta is slight to the extent, I believe, that it
> would be justified to discard the CCRMA version:
> * .gitignore added to GitHub version
> * CCRMA version spells "CoreMIDI" as "CoreMidi" in configure.ac,
> src/RtMidi.cpp, and in doc/doxygen (CoreMIDI should be preferred as acronyms
> are capitalised)
> * CCRMA version adds doc/html (redundant as they're available online)
> * CCRMA version adds projects/examples/libMakefile (redundant as GitHub also
> has it as libMakefile.in in same directory)
>
> Clearly, 4.5.1 on CCRMA has been superseded by 4.5.2 on GitHub.
>
> Moving forwards:
>
> * I believe that the code on the CCRMA website should mirror the one on
> GitHub, because all the development, issue-tracking, and pull-requests is
> done on GitHub. The code is developed on GitHub, it should originate from
> GitHub, the CCRMA website can then mirror it (or just link to it). I think
> we can discard the CCRMA version, and have the download page
> (https://ccrma.stanford.edu/software/stk/download.html) simply link to the
> GitHub repo (the changelog is useful and can be transferred to a CHANGELOG
> file we'd add to the repo)
>
> * Given that 55 commits have accumulated since GitHub's 4.5.1 release two
> years ago, we should make a new release on GitHub. (On a general note, every
> version number change should be a release, but making a release actually
> only involves pushing a tag to the repository, GitHub automatically creates
> the release for us).
>
> Also, I'd be happy to manage new releases and can push 4.6.0 now with the 55
> commits that have accumulated :-)
>
> Thoughts?
>
> Regarding issues, many are indeed stagnant, I'll ping the owners so that we
> can move forwards with them or close them.
>
> Ariel
>
>
> On Fri, Aug 5, 2016 at 6:16 PM, Gary Scavone <gary at ccrma.stanford.edu>
> wrote:
>>
>> Hi Ariel,
>>
>> Thanks for the offer to help.  The current release is only about 6 months
>> old, which is fairly “new” from my perspective.  And unless I’m missing
>> something, there has only been one merged pull request since then.  The two
>> pending pull requests have been replied to but I didn’t get subsequent
>> feedback from the contributors.  My feeling is that #58 is not a bug but
>> rather based on the contributor using the class in an incorrect way.
>>
>> There are several “issues", but I don’t know when I would be able to
>> address them.  In general, if someone wants something fixed, they should fix
>> it themselves and then submit a pull request.
>>
>> There have been a number of updates to the RtMidi and RtAudio classes, but
>> again, I’m not sure they are significant enough to substantiate a new
>> release.
>>
>> Regards,
>>
>> —gary
>>
>> On Aug 3, 2016, at 8:36 AM, Ariel Elkin <arielelkin at gmail.com> wrote:
>>
>> Hi all,
>>
>> Several bug fixes and improvements have been accumulating since v4.5.2,
>> it'd be good to draft a new release.
>>
>> Also, two pull requests need to be reviewed:
>> https://github.com/thestk/stk/pulls
>>
>> And issues have also been accumulating:
>> https://github.com/thestk/stk/issues
>>
>> As far as I'm concerned, I can (as always) provide all the support needed
>> for iOS, but I don't have (at this stage) the required background knowledge
>> for maintaining an STK project on OS X, nor a Linux or Windows machine for
>> development.
>>
>> So I think it would be good if we clarify who is responsible for dealing
>> with new issues, pull requests, and overall maintenance. This would make
>> maintenance and development more efficient in the long term.
>>
>> Ariel
>> _______________________________________________
>> Stk mailing list
>> Stk at ccrma.stanford.edu
>> https://cm-mail.stanford.edu/mailman/listinfo/stk
>>
>>
>
>



More information about the Stk mailing list