<html><head></head><body bgcolor="#FFFFFF"><div>Yes that's a good idea and similar in many ways to what tuncer suggested so +1 on both counts. </div><div><br></div><div>Nonetheless I am of the opinion that binary packages are simpler for the publication tool author as they push the build responsibility to the library author <br>To configure their project and travis hooks accordingly.</div><div><br></div><div>Hackage is a good example architecture in many ways though.<br><br></div><div><br>On 7 May 2012, at 14:31, Tristan Sloughter <<a href="mailto:tristan.sloughter@gmail.com">tristan.sloughter@gmail.com</a>> wrote:<br><br></div><div></div><blockquote type="cite"><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">> 7) Binary or source packages?<br>
><br>
> - Ummm - tricky<br>
><br>
<br>
</div>I think binary is better but adds a lot of complexity. Erts versions, projects containing native code, etc. makin this the publishers responsibility means the tool only has to focus on the packaging problem not the build space. Third party signing allows you to support sources which gaven't been published by the originator.<br>
</blockquote><div><br></div><div>I'd be happy with starting with just a source solution, but I think a binary one is definitely needed and can be simplified with TravisCI -- it'll build with multiple Erlang versions.</div>
<div><br></div><div>I really wish I could plugin to the hosted TravisCI to have a job run to publish artifacts. I only briefly looked into that, so maybe something there is possible.</div><div><br></div><div>Tristan</div>
</div>
</div></blockquote></body></html>