<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="yiv8413194560"><div id="yui_3_16_0_ym19_1_1489535137534_14148"><div style="color:#000;background-color:#fff;font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px;" id="yui_3_16_0_ym19_1_1489535137534_14147"><div id="yiv8413194560yui_3_16_0_ym19_1_1489505452901_7751"><div id="yui_3_16_0_ym19_1_1489535137534_15282">Hello,</div><div id="yui_3_16_0_ym19_1_1489535137534_15257"><br></div><div id="yui_3_16_0_ym19_1_1489535137534_15377">Albert provided some comments on the issue tracker about how to <br></div><div id="yui_3_16_0_ym19_1_1489535137534_23469">handle the release process for Purr Data. I want to move that discussion <br></div><div id="yui_3_16_0_ym19_1_1489535137534_23471">here. This is a fairly clear case where Albert has experience in this <br></div><div dir="ltr" id="yui_3_16_0_ym19_1_1489535137534_24674">domain that can improve upon the current brittle process. I want to use this <br></div><div dir="ltr" id="yui_3_16_0_ym19_1_1489535137534_32661">clear case to explicitly and publicly request mentorship, and to see if this kind <br></div><div dir="ltr" id="yui_3_16_0_ym19_1_1489535137534_32662">of explicit request works as a general process for future development.<br></div><div id="yui_3_16_0_ym19_1_1489535137534_32669"><br></div><div id="yui_3_16_0_ym19_1_1489535137534_32689">The problem is twofold: I'm not (yet) using tags in git for the releases, and <br></div><div id="yui_3_16_0_ym19_1_1489535137534_33888">I don't have a scalable process for publishing and archiving the <br></div><div dir="ltr" id="yui_3_16_0_ym19_1_1489535137534_34993">release binaries. In fact, I'm not even archiving the release binaries.</div><div dir="ltr" id="yui_3_16_0_ym19_1_1489535137534_35041"><br></div><div dir="ltr" id="yui_3_16_0_ym19_1_1489535137534_36126">I think tagging is fairly straightforward. Do we need to specify a format <br></div><div dir="ltr" id="yui_3_16_0_ym19_1_1489535137534_36127">for the text of the tag? $major.$minor.$bugfix, v$major.$minor.$bugfix, <br></div><div dir="ltr" id="yui_3_16_0_ym19_1_1489535137534_39591">etc.<br></div><div id="yui_3_16_0_ym19_1_1489535137534_39595"><br></div><div id="yui_3_16_0_ym19_1_1489535137534_39668">Publishing: it seems like I should be able to use gitlab ci for this. Currently <br></div><div dir="ltr" id="yui_3_16_0_ym19_1_1489535137534_41903">the ci binaries (called "artifacts") last a day and are then removed to save <br></div><div dir="ltr" id="yui_3_16_0_ym19_1_1489535137534_41904">space. I could add a rule that when a release tag is pushed then the ci <br></div><div dir="ltr" id="yui_3_16_0_ym19_1_1489535137534_41905">builds binaries that never get removed. Then we'd host the full archive of <br></div><div dir="ltr" id="yui_3_16_0_ym19_1_1489535137534_41973">releases in gitlab, plus the temporary binaries that come from merges.</div><div dir="ltr" id="yui_3_16_0_ym19_1_1489535137534_41975"><br></div><div dir="ltr" id="yui_3_16_0_ym19_1_1489535137534_41977">However, that would mean that I push the release tag to *trigger* the build <br></div><div dir="ltr" id="yui_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></div><div dir="ltr" id="yui_3_16_0_ym19_1_1489535137534_47836">that.<br></div><div id="yui_3_16_0_ym19_1_1489535137534_41981"><br></div><div id="yui_3_16_0_ym19_1_1489535137534_41983">Anyway, what I'd like to end up with is an automated system where all that's <br></div><div dir="ltr" id="yui_3_16_0_ym19_1_1489535137534_43161">needed is a single git push to start the release process, build the binaries, and <br></div><div dir="ltr" id="yui_3_16_0_ym19_1_1489535137534_43163">upload them to the relevant location(s). Currently I'm manually uploading binaries <br></div><div dir="ltr" id="yui_3_16_0_ym19_1_1489535137534_43165">build by gitlab ci to a "purr-data-binaries" repo, which is a waste of time.</div><div dir="ltr" id="yui_3_16_0_ym19_1_1489535137534_44276"><br></div><div dir="ltr" id="yui_3_16_0_ym19_1_1489535137534_45446">I'm also fine with using github to publish the binaries and/or store the older <br></div><div dir="ltr" id="yui_3_16_0_ym19_1_1489535137534_46555">versions. But is there a way to automate the process of uploading the binaries <br></div><div dir="ltr" id="yui_3_16_0_ym19_1_1489535137534_46556">to github from gitlab ci?</div><div dir="ltr" id="yui_3_16_0_ym19_1_1489535137534_46578"><br></div><div dir="ltr" id="yui_3_16_0_ym19_1_1489535137534_46637">Finally, I realize I still don't have Windows as part of the ci process. But for <br></div><div dir="ltr" id="yui_3_16_0_ym19_1_1489535137534_47721">now let's just assume I'll have one, as well as one for OSX 10.8 and <br></div><div dir="ltr" id="yui_3_16_0_ym19_1_1489535137534_47722">rpi.</div><div dir="ltr" id="yui_3_16_0_ym19_1_1489535137534_47724"><br></div><div dir="ltr" id="yui_3_16_0_ym19_1_1489535137534_47726">-Jonathan<br></div></div></div></div></div></div></body></html>