[Stk] New release and maintenance

Stephen Sinclair radarsat1 at gmail.com
Tue Aug 9 08:10:22 PDT 2016 

Sorry, didn't realize that 4.5.2 shouldn't have happened at all.. I've
deleted the tag.  So we just need to put 4.5.1 where it goes.

Steve


On Tue, Aug 9, 2016 at 11:07 AM, Gary Scavone <gary at ccrma.stanford.edu> wrote:
> Hi Ariel,
>
> First, the CCRMA website is for “users.”  The GitHub site is for developers.
> The CCRMA site includes compiled versions of the documentation and the
> configure script, while the GitHub repo does not.  It is impossible that
> having the two sites can cause any problems, since the only time that the
> CCRMA site is updates is when I make a new release on GitHub.
>
> I am currently away visiting family and on holiday all next week, so I don’t
> know if I will have time to investigate what happened with the dates on the
> repo (as well as why there is a release 4.5.2, which shouldn’t have been
> made without my approval). But all that needs to happen is that the  GitHub
> repo be fixed (hopefully, it is just a tagging issue as Stephen has
> suggested).
>
> Regards,
>
> —gary
>
> On 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.
>
> Ariel
>
> On Mon, Aug 8, 2016 at 6:41 PM, Stephen Sinclair <radarsat1 at gmail.com>
> wrote:
>>
>> 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