<html><head></head><body><div style="color:#000; background-color:#fff; font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px"><div id="yui_3_16_0_ym19_1_1489709604041_17502">Thanks, Albert.</div><div id="yui_3_16_0_ym19_1_1489709604041_17562"><br></div><div id="yui_3_16_0_ym19_1_1489709604041_17563">The tags should be pretty easy. I'll start with those when I get a chance.</div><div id="yui_3_16_0_ym19_1_1489709604041_17692"><br></div><div id="yui_3_16_0_ym19_1_1489709604041_17662">I can probably just re-run the ci for the missing 2.0 binaries. That will at least <br></div><div id="yui_3_16_0_ym19_1_1489709604041_17664">get me Linux and OSX 10.11 binaries.</div><div><br></div><div>-Jonathan<br></div><div id="yui_3_16_0_ym19_1_1489709604041_17517"><br></div><div class="qtdSeparateBR"><br><br></div><div class="yahoo_quoted" id="yui_3_16_0_ym19_1_1489709604041_17514" style="display: block;"><div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;" id="yui_3_16_0_ym19_1_1489709604041_17513"><div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;" id="yui_3_16_0_ym19_1_1489709604041_17512"><div class="y_msg_container" id="yui_3_16_0_ym19_1_1489709604041_17511"><div id="yiv6606375678"><div id="yui_3_16_0_ym19_1_1489709604041_17510"><div dir="ltr" id="yui_3_16_0_ym19_1_1489709604041_17509"><div class="yiv6606375678gmail_extra" id="yui_3_16_0_ym19_1_1489709604041_17508"><div class="yiv6606375678gmail_quote" id="yui_3_16_0_ym19_1_1489709604041_17507">On Wed, Mar 15, 2017 at 1:29 AM, Jonathan Wilkes <span dir="ltr"><<a rel="nofollow" shape="rect" ymailto="mailto:jancsika@yahoo.com" target="_blank" href="mailto:jancsika@yahoo.com">jancsika@yahoo.com</a>></span> wrote:<br clear="none"><blockquote class="yiv6606375678gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex;" id="yui_3_16_0_ym19_1_1489709604041_17539"><div id="yui_3_16_0_ym19_1_1489709604041_17538"><div style="color:rgb(0,0,0);background-color:rgb(255,255,255);font-family:helveticaneue, helvetica neue, helvetica, arial, lucida grande, sans-serif;font-size:16px;" id="yui_3_16_0_ym19_1_1489709604041_17537"><div id="yiv6606375678gmail-m_8058072566779469019yiv8413194560"><div id="yiv6606375678gmail-m_8058072566779469019yui_3_16_0_ym19_1_1489535137534_14148"><div id="yiv6606375678gmail-m_8058072566779469019yui_3_16_0_ym19_1_1489535137534_14147" style="color:rgb(0,0,0);background-color:rgb(255,255,255);font-family:helveticaneue, helvetica neue, helvetica, arial, lucida grande, sans-serif;font-size:16px;"><div id="yiv6606375678gmail-m_8058072566779469019yiv8413194560yui_3_16_0_ym19_1_1489505452901_7751">Albert provided some comments on the issue tracker about how to <br clear="none"><div id="yiv6606375678gmail-m_8058072566779469019yui_3_16_0_ym19_1_1489535137534_23469">handle the release process for Purr Data.</div></div></div></div></div></div></div></blockquote><div id="yui_3_16_0_ym19_1_1489709604041_17778"><br clear="none"></div><div id="yui_3_16_0_ym19_1_1489709604041_17540">Just for the record, my comments start with this post here: <a rel="nofollow" shape="rect" target="_blank" href="https://git.purrdata.net/jwilkes/purr-data/merge_requests/83#note_2538" id="yui_3_16_0_ym19_1_1489709604041_17541">https://git.purrdata.net/jwilkes/purr-data/merge_requests/83#note_2538</a><br clear="none"><br clear="none"></div><div id="yui_3_16_0_ym19_1_1489709604041_17542">The TL;DR version is: (1) We need to tag the releases in Purr Data's source repo, which is easy to do, and (2) we need to upload the binary packages to permanent cloud storage somewhere, which doesn't seem to be so easy in Gitlab. Also, Gitlab doesn't present the downloads in a convenient way that makes it easy for users to find them.<br clear="none"><br clear="none"></div><div>That's why I suggested to use a mirror of the Gitlab source repo on Github for that purpose. Github has a very nice and simple-to-use release subsystem, basically you add some release notes to the tag marking the release, upload the binary packages and you're done.<br clear="none"><br clear="none">I've already set up a mirror there, so you can all have a look: <a rel="nofollow" shape="rect" target="_blank" href="https://github.com/agraef/purr-data">https://github.com/agraef/purr-data</a>. Click on "releases", or follow this link: <a rel="nofollow" shape="rect" target="_blank" href="https://github.com/agraef/purr-data/releases">https://github.com/agraef/purr-data/releases</a>. All releases are right there on a single page, with the latest release on top, and it's easy to find the packages in the Downloads section of each release.<br clear="none"></div><div><br clear="none"></div><div>(Jonathan, btw, if you still have the remaining 2.0 binaries lying around somewhere, please toss them my way so that I can upload them there, thanks.)<br clear="none"><br clear="none"></div><blockquote class="yiv6606375678gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex;"><div><div style="color:rgb(0,0,0);background-color:rgb(255,255,255);font-family:helveticaneue, helvetica neue, helvetica, arial, lucida grande, sans-serif;font-size:16px;"><div id="yiv6606375678gmail-m_8058072566779469019yiv8413194560"><div id="yiv6606375678gmail-m_8058072566779469019yui_3_16_0_ym19_1_1489535137534_14148"><div id="yiv6606375678gmail-m_8058072566779469019yui_3_16_0_ym19_1_1489535137534_14147" style="color:rgb(0,0,0);background-color:rgb(255,255,255);font-family:helveticaneue, helvetica neue, helvetica, arial, lucida grande, sans-serif;font-size:16px;"><div id="yiv6606375678gmail-m_8058072566779469019yiv8413194560yui_3_16_0_ym19_1_1489505452901_7751"><div dir="ltr" id="yiv6606375678gmail-m_8058072566779469019yui_3_16_0_ym19_1_1489535137534_36126">I think tagging is fairly straightforward. Do we need to specify a format <br clear="none"></div><div dir="ltr" id="yiv6606375678gmail-m_8058072566779469019yui_3_16_0_ym19_1_1489535137534_36127">for the text of the tag? $major.$minor.$bugfix, v$major.$minor.$bugfix, <br clear="none"></div><div dir="ltr" id="yiv6606375678gmail-m_8058072566779469019yui_3_16_0_ym19_1_1489535137534_39591">etc.<br clear="none"></div></div></div></div></div></div></div></blockquote><div><br clear="none"></div><div>Some people use the "v" prefix, but IMHO it's redundant, so I'd prefer just the naked version number.<br clear="none"><br clear="none"></div><blockquote class="yiv6606375678gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex;"><div><div style="color:rgb(0,0,0);background-color:rgb(255,255,255);font-family:helveticaneue, helvetica neue, helvetica, arial, lucida grande, sans-serif;font-size:16px;"><div id="yiv6606375678gmail-m_8058072566779469019yiv8413194560"><div id="yiv6606375678gmail-m_8058072566779469019yui_3_16_0_ym19_1_1489535137534_14148"><div id="yiv6606375678gmail-m_8058072566779469019yui_3_16_0_ym19_1_1489535137534_14147" style="color:rgb(0,0,0);background-color:rgb(255,255,255);font-family:helveticaneue, helvetica neue, helvetica, arial, lucida grande, sans-serif;font-size:16px;"><div id="yiv6606375678gmail-m_8058072566779469019yiv8413194560yui_3_16_0_ym19_1_1489505452901_7751"><div dir="ltr" id="yiv6606375678gmail-m_8058072566779469019yui_3_16_0_ym19_1_1489535137534_39591"></div><div id="yiv6606375678gmail-m_8058072566779469019yui_3_16_0_ym19_1_1489535137534_39595"></div><div id="yiv6606375678gmail-m_8058072566779469019yui_3_16_0_ym19_1_1489535137534_39668">Publishing: it seems like I should be able to use gitlab ci for this. Currently <br clear="none"></div><div dir="ltr" id="yiv6606375678gmail-m_8058072566779469019yui_3_16_0_ym19_1_1489535137534_41903">the ci binaries (called "artifacts") last a day and are then removed to save <br clear="none"></div><div dir="ltr" id="yiv6606375678gmail-m_8058072566779469019yui_3_16_0_ym19_1_1489535137534_41904">space. I could add a rule that when a release tag is pushed then the ci <br clear="none"></div><div dir="ltr" id="yiv6606375678gmail-m_8058072566779469019yui_3_16_0_ym19_1_1489535137534_41905">builds binaries that never get removed. Then we'd host the full archive of <br clear="none"></div><div dir="ltr" id="yiv6606375678gmail-m_8058072566779469019yui_3_16_0_ym19_1_1489535137534_41973">releases in gitlab, plus the temporary binaries that come from merges.</div></div></div></div></div></div></div></blockquote><div><br clear="none"></div><div>That would be nice to have. Then instead of uploading the packages at the Github mirror, one could simply link to the binaries on Gitlab in the release notes. OTOH, it can't hurt to have a backup of the packages on Github.<br clear="none"> <br clear="none"></div><blockquote class="yiv6606375678gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex;" id="yui_3_16_0_ym19_1_1489709604041_17548"><div id="yui_3_16_0_ym19_1_1489709604041_17547"><div style="color:rgb(0,0,0);background-color:rgb(255,255,255);font-family:helveticaneue, helvetica neue, helvetica, arial, lucida grande, sans-serif;font-size:16px;" id="yui_3_16_0_ym19_1_1489709604041_17546"><div id="yiv6606375678gmail-m_8058072566779469019yiv8413194560"><div id="yiv6606375678gmail-m_8058072566779469019yui_3_16_0_ym19_1_1489535137534_14148"><div id="yiv6606375678gmail-m_8058072566779469019yui_3_16_0_ym19_1_1489535137534_14147" style="color:rgb(0,0,0);background-color:rgb(255,255,255);font-family:helveticaneue, helvetica neue, helvetica, arial, lucida grande, sans-serif;font-size:16px;"><div id="yiv6606375678gmail-m_8058072566779469019yiv8413194560yui_3_16_0_ym19_1_1489505452901_7751"><div dir="ltr" id="yiv6606375678gmail-m_8058072566779469019yui_3_16_0_ym19_1_1489535137534_41975"></div><div dir="ltr" id="yiv6606375678gmail-m_8058072566779469019yui_3_16_0_ym19_1_1489535137534_41977">However, that would mean that I push the release tag to *trigger* the build <br clear="none"></div><div dir="ltr" id="yiv6606375678gmail-m_8058072566779469019yui_3_16_0_ym19_1_1489535137534_41979">of release binaries. Not sure if that's a problem, or if there's a workaround for <br clear="none"></div><div dir="ltr" id="yiv6606375678gmail-m_8058072566779469019yui_3_16_0_ym19_1_1489535137534_47836">that.<br clear="none"></div></div></div></div></div></div></div></blockquote><div><br clear="none"></div><div id="yui_3_16_0_ym19_1_1489709604041_17543">I don't see a problem there. While rewriting commit history on the master branch is generally bad and not permitted (with good reason) the way repos are typically set up on Gitlab and Github, "repairing" release tags is not a big deal and can be done at any time, as long as the release isn't really "out there" yet. So, if you notice that you forgot something or made a mistake, you just stop the release CI pipeline and delete the build artifacts, do whatever hot fixes are needed and push them, then do a `git tag -f` and force-push the tag again when you're done.<br clear="none"><br clear="none">Once the CI build is through, if you're fine with everything, you just drop me (or whoever is our release manager at the time) an email that release x.y.z is out and your release notes to go along with that, and Mr./Mrs. RM will take care of putting it up on the Github mirror, at which point it's going to be available and easy to find for everyone.<br clear="none"><br clear="none"> The idea there is that we'd use the Github mirror for publishing the releases (along with a mirror of the source repo), so we can play around on Gitlab as long as needed until you think it's time for a release. Of course, once the release landed on Github, it is "out there", so there's no going back, and any further fixes will need a new release.<br clear="none"><br clear="none"></div><div>I think that this process is sensible and workable, and it allows Gitlab to be used as the "lab" in which we work on things until they're done, and the Github mirror as our "outlet" to present the shiny results.<br clear="none"></div><div><br clear="none"></div><blockquote class="yiv6606375678gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex;"><div><div style="color:rgb(0,0,0);background-color:rgb(255,255,255);font-family:helveticaneue, helvetica neue, helvetica, arial, lucida grande, sans-serif;font-size:16px;"><div id="yiv6606375678gmail-m_8058072566779469019yiv8413194560"><div id="yiv6606375678gmail-m_8058072566779469019yui_3_16_0_ym19_1_1489535137534_14148"><div id="yiv6606375678gmail-m_8058072566779469019yui_3_16_0_ym19_1_1489535137534_14147" style="color:rgb(0,0,0);background-color:rgb(255,255,255);font-family:helveticaneue, helvetica neue, helvetica, arial, lucida grande, sans-serif;font-size:16px;"><div id="yiv6606375678gmail-m_8058072566779469019yiv8413194560yui_3_16_0_ym19_1_1489505452901_7751"><div dir="ltr" id="yiv6606375678gmail-m_8058072566779469019yui_3_16_0_ym19_1_1489535137534_45446">I'm also fine with using github to publish the binaries and/or store the older <br clear="none"></div><div dir="ltr" id="yiv6606375678gmail-m_8058072566779469019yui_3_16_0_ym19_1_1489535137534_46555">versions. But is there a way to automate the process of uploading the binaries <br clear="none"></div><div dir="ltr" id="yiv6606375678gmail-m_8058072566779469019yui_3_16_0_ym19_1_1489535137534_46556">to github from gitlab ci?</div></div></div></div></div></div></div></blockquote><div><br clear="none"></div><div id="yui_3_16_0_ym19_1_1489709604041_17545">Well, we do need to come up with some sensible release notes, I don't see how we could automate that. :) And after entering those you can just as well push a button, select the binaries on your local hard drive, and add them to the release, simple as that. I'm not sure whether Github offers an API to automate that process, but it's not really needed, as the process is so easy. And some things are still better done by humans, even in this day and age. ;-)<br clear="none"><br clear="none">Of course this manual publishing of releases won't scale up when you start doing releases *very* frequently (weekly or even daily), but I don't see that happening yet, so let's talk about that if and when the need arises.<br clear="none"><br clear="none"></div><div id="yui_3_16_0_ym19_1_1489709604041_17544">I can take care of the Github part of the releases for now, until someone else steps up to become our release master. Any proposals yet? :)<br clear="none"></div><div><br clear="none"></div><div>Cheers.<div class="yiv6606375678yqt8608134890" id="yiv6606375678yqtfd98203"><br clear="none"></div></div><div class="yiv6606375678yqt8608134890" id="yiv6606375678yqtfd49896">Albert</div><br clear="none"></div><br clear="none">-- <br clear="none"><div class="yiv6606375678gmail_signature"><div dir="ltr">Dr. Albert Gr"af<br clear="none">Computer Music Research Group, JGU Mainz, Germany<br clear="none">Email: <a rel="nofollow" shape="rect" ymailto="mailto:aggraef@gmail.com" target="_blank" href="mailto:aggraef@gmail.com">aggraef@gmail.com</a><br clear="none">WWW: <a rel="nofollow" shape="rect" target="_blank" href="https://plus.google.com/+AlbertGraef">https://plus.google.com/+AlbertGraef</a></div></div><div class="yiv6606375678yqt8608134890" id="yiv6606375678yqtfd13737">
</div></div></div></div></div><br><br></div> </div> </div> </div></div></body></html>