<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jun 24, 2014 at 9:33 PM, Janosch Machowinski <span dir="ltr"><<a href="mailto:Janosch.Machowinski@dfki.de" target="_blank">Janosch.Machowinski@dfki.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey,<br>
after reading all of this about snapshots I was wondering,<br>
if going for real releases wouldn't be the better option.<br>
This would cover both working scenarios:<br></blockquote><div>Agreed. We're past this already (I believe).</div><div><br></div><div>The issue is not anymore for the rock core code (which, I agree with you, should have proper releases that people can track), but the rest of the code, i.e. the project's own code or other packages that are shared across projects but are not part of rock. For those, you won't have proper releases, stuff can still break two days before a demo and boom. Once the demo is passed, it is also important to still be able to replicate the demo's code and so on. And what about one updates to a new rock release but notices only a few weeks later that something breaks ?</div>
<div><br></div><div>The other nice side-effect of having a global history is that one can do a global bisect ... :P </div><div><br></div><div>Sylvain</div></div></div></div>