<div dir="ltr"><div>This sounds good to me.</div><div><br></div><div>In the past, one of the things that contributed to having so many release candidates was lack of confidence in the test suite. There was an idea that for a swift release to be tested well, it needed to be run by real users with real scripts on a cluster. So we would create a release candidate, wait for feedback, find a bug that the test suite didn't catch, release a new release candidate, wait for feedback, find another issue, and end up with 7 release candidates over 6 months.<br></div><div><br></div><div>I think continued improvements to the test suite will help a lot in your goal of more stable and more frequent releases.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 16, 2014 at 11:37 AM, Yadu Nand Babuji <span dir="ltr"><<a href="mailto:yadunand@uchicago.edu" target="_blank">yadunand@uchicago.edu</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Mihael,<br>
<br>
So, testing -> RC -> Release, but the time to spent in RC should be<br>
brought down,<br>
and that needs better testing with clearly defined test areas.<br>
<span class="HOEnZb"><font color="#888888"><br>
-Yadu<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On 12/15/2014 04:10 PM, Mihael Hategan wrote:<br>
> Hi,<br>
><br>
> One comment. I'm not sure if I am against release candidates. However,<br>
> we have, I think, gone overboard with them in that many releases were<br>
> held because maybe there were bugs, except the rate at which they were<br>
> uncovered was very low.<br>
><br>
> So I think we should have RCs. But we shouldn't have 6 RCs, and we<br>
> shouldn't keep an RC without a release for 6 months.<br>
><br>
> Mihael<br>
><br>
> On Mon, 2014-12-15 at 15:58 -0600, Yadu Nand Babuji wrote:<br>
>> Hi Everyone,<br>
>><br>
>> Based on the discussion we had on the Friday meeting, here are some of<br>
>> the suggested changes to release<br>
>> strategy and versioning. Please correct me if I got any of the following<br>
>> wrong.<br>
>><br>
>> Major version will denote language changes that will likely break<br>
>> backward compatibility.<br>
>> Minor version increments will indicate feature enhancements.<br>
>> Sub-minor versions will be assigned after a release has been made, and<br>
>> will represent bug-fixes.<br>
>> testing versions for the next release which will be closely following<br>
>> the repository.<br>
>> No more RCs<br>
>><br>
>> We will not be using the release-candidate numbering which has put<br>
>> releases in perpetual limbo, instead<br>
>> testing releases with no explicit numbering will be used. For example<br>
>> the next planned release 0.96 would<br>
>> have a testing branch 0.96-testing. Once planned features have gone in<br>
>> and are tested, 0.96 will be released,<br>
>> with bug fixes following it, when identified.<br>
>><br>
>> I will work with the site admins (midway, beagle, LCRC etc..) to ensure<br>
>> that we have the latest stable release<br>
>> as well as the testing package for the next release available on the<br>
>> login-nodes.<br>
>><br>
>> Thanks,<br>
>> Yadu<br>
>><br>
>> _______________________________________________<br>
>> Swift-devel mailing list<br>
>> <a href="mailto:Swift-devel@ci.uchicago.edu">Swift-devel@ci.uchicago.edu</a><br>
>> <a href="https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel" target="_blank">https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel</a><br>
><br>
<br>
_______________________________________________<br>
Swift-devel mailing list<br>
<a href="mailto:Swift-devel@ci.uchicago.edu">Swift-devel@ci.uchicago.edu</a><br>
<a href="https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel" target="_blank">https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel</a><br>
</div></div></blockquote></div></div>