<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>I'd agree <br><br>Sent from my iPhone</div><div><br>On Aug 8, 2016, at 6:34 AM, Ariel Elkin <<a href="mailto:arielelkin@gmail.com">arielelkin@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">Hi Gary,<div><br></div><div>Then it looks like there might be a discrepancy in the STK's distribution channels...</div><div><br></div><div>On the CCRMA website, the current release is 4.5.1 and dates from February 2016</div><div><a href="https://ccrma.stanford.edu/software/stk/download.html">https://ccrma.stanford.edu/software/stk/download.html</a><br><div><br></div><div>On GitHub, the current release is 4.5.2 and is actually two years old: </div><div><a href="https://github.com/thestk/stk/releases">https://github.com/thestk/stk/releases</a> <br><div><br></div><div>Messy. We're forking ourselves. Must be be tidied up. </div><div><br></div><div>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. </div><div><br></div><div>The first thing we should do is figure out the differences between the codebase on the CCRMA website and the codebase on GitHub:</div><div><br></div><div>Download both:</div><div><a href="https://github.com/thestk/stk/archive/master.zip">https://github.com/thestk/stk/archive/master.zip</a><br></div><div><a href="http://ccrma.stanford.edu/software/stk/release/stk-4.5.1.tar.gz">http://ccrma.stanford.edu/software/stk/release/stk-4.5.1.tar.gz</a><br></div><div><br></div><div>Unzip them, then run:</div><div>$opendiff ~/Downloads/stk-master ~/Downloads/stk-4.5.1</div><div><br></div><div>you'll notice that the delta is slight to the extent, I believe, that it would be justified to discard the CCRMA version:</div><div>* .gitignore added to GitHub version</div><div>* CCRMA version spells "CoreMIDI" as "CoreMidi" in <a href="http://configure.ac">configure.ac</a>, src/RtMidi.cpp, and in doc/doxygen (CoreMIDI should be preferred as acronyms are capitalised)<br></div><div>* CCRMA version adds doc/html (redundant as they're available online)</div><div>* CCRMA version adds projects/examples/libMakefile (redundant as GitHub also has it as libMakefile.in in same directory)</div><div><br></div><div>Clearly, 4.5.1 on CCRMA has been superseded by 4.5.2 on GitHub. </div><div><br></div><div>Moving forwards:</div><div><br></div><div>* 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 (<a href="https://ccrma.stanford.edu/software/stk/download.html">https://ccrma.stanford.edu/software/stk/download.html</a>) simply link to the GitHub repo (the changelog is useful and can be transferred to a CHANGELOG file we'd add to the repo)</div><div><br></div><div>* 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). </div><div><br></div><div>Also, I'd be happy to manage new releases and can push 4.6.0 now with the 55 commits that have accumulated :-)</div><div><br></div><div>Thoughts?</div><div><br></div><div>Regarding issues, many are indeed stagnant, I'll ping the owners so that we can move forwards with them or close them.</div><div><br></div><div>Ariel</div><div><br></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 5, 2016 at 6:16 PM, Gary Scavone <span dir="ltr"><<a href="mailto:gary@ccrma.stanford.edu" target="_blank">gary@ccrma.stanford.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word">Hi Ariel,<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Regards,</div><div><br></div><div>—gary</div><div><br><div><blockquote type="cite"><span class=""><div>On Aug 3, 2016, at 8:36 AM, Ariel Elkin <<a href="mailto:arielelkin@gmail.com" target="_blank">arielelkin@gmail.com</a>> wrote:</div><br></span><div><div><div class="h5"><div dir="ltr"><font size="3">Hi all,</font><div><font size="3"><br></font></div><div><font size="3">Several bug fixes and improvements have been accumulating since v4.5.2, it'd be good to draft a new release. </font></div><div><font size="3"><br></font></div><div><font size="3">Also, two pull requests need to be reviewed:</font></div><div><font size="3"><a href="https://github.com/thestk/stk/pulls" target="_blank">https://github.com/thestk/stk/<wbr>pulls</a><br></font></div><div><font size="3"><br></font></div><div><font size="3">And i</font><span style="font-size:inherit">ssues have also been accumulating:</span></div><div><span style="font-size:inherit"><a href="https://github.com/thestk/stk/issues" target="_blank">https://github.com/thestk/stk/<wbr>issues</a></span></div><div><span style="font-size:inherit"><br></span></div><div><span style="font-size:inherit">As far as I'm concerned, I can </span><span style="font-size:inherit">(as always) </span><span style="font-size:inherit">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. </span><span style="font-size:inherit"><br></span></div><div><span style="font-size:inherit"><br>So I think it would be good if </span><span style="font-size:inherit">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.</span></div><div><span style="font-size:inherit"><br></span></div><div><span style="font-size:inherit">Ariel</span></div></div></div></div><span class="">
______________________________<wbr>_________________<br>Stk mailing list<br><a href="mailto:Stk@ccrma.stanford.edu" target="_blank">Stk@ccrma.stanford.edu</a><br><a href="https://cm-mail.stanford.edu/mailman/listinfo/stk" target="_blank">https://cm-mail.stanford.edu/<wbr>mailman/listinfo/stk</a><br></span></div></blockquote></div><br></div></div></blockquote></div><br></div></div></div></div></div></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>Stk mailing list</span><br><span><a href="mailto:Stk@ccrma.stanford.edu">Stk@ccrma.stanford.edu</a></span><br><span><a href="https://cm-mail.stanford.edu/mailman/listinfo/stk">https://cm-mail.stanford.edu/mailman/listinfo/stk</a></span><br></div></blockquote></body></html>