<div dir="ltr">Before we have an idea for a transition plan, I would argue that we should have an implementation plan... As you mention, autoproj commit / autoproj tag have to be implemented prior to the release management changes.<div>
<br></div><div>Here comes the neverending question: who has the time ?<br><div><br></div><div>Sylvain</div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jul 10, 2014 at 10:00 AM, Jakob Schwendner <span dir="ltr"><<a href="mailto:jakob.schwendner@dfki.de" target="_blank">jakob.schwendner@dfki.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
Any ideas on a transition plan for these changes? I guess the autoproj commit feature could be independent from having releases instead of our master/next/stable cycle.<br>
<br>
Cheers,<br>
<br>
Jakob<br>
<div class="HOEnZb"><div class="h5"><br>
> -----Original Message-----<br>
> From: <a href="mailto:rock-dev-bounces@dfki.de">rock-dev-bounces@dfki.de</a> [mailto:<a href="mailto:rock-dev-bounces@dfki.de">rock-dev-bounces@dfki.de</a>] On<br>
> Behalf Of Sylvain Joyeux<br>
> Sent: Dienstag, 1. Juli 2014 11:21<br>
> To: Steffen Planthaber<br>
> Cc: <a href="mailto:rock-dev@dfki.de">rock-dev@dfki.de</a><br>
> Subject: Re: [Rock-dev] Flavours, freezes, updates<br>
><br>
> Thanks Steffen, your summary is IMO quite accurate.<br>
><br>
><br>
> Using the tags you can easily find and reproduce former states of the<br>
> software. This is only true for a complete snapshot of all packages, so<br>
> it it only useful directly after a autoproj commit. Both can be<br>
> combined<br>
> into a single command<br>
><br>
><br>
> They can, but they should not IMO. The same way than git commit and git tag<br>
> are two different things, I would keep autoproj commit and autoproj tag<br>
> separate. If only to reuse prior knowledge about git.<br>
><br>
> Sylvain<br>
<br>
</div></div></blockquote></div><br></div>