[Swift-devel] Release strategy

[David Kelly]

This sounds good to me.

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.

I think continued improvements to the test suite will help a lot in your
goal of more stable and more frequent releases.

On Tue, Dec 16, 2014 at 11:37 AM, Yadu Nand Babuji <yadunand at uchicago.edu>
wrote:
>
> Hi Mihael,
>
> So, testing -> RC -> Release, but the time to spent in RC should be
> brought down,
> and that needs better testing with clearly defined test areas.
>
> -Yadu
>
> On 12/15/2014 04:10 PM, Mihael Hategan wrote:
> > Hi,
> >
> > One comment. I'm not sure if I am against release candidates. However,
> > we have, I think, gone overboard with them in that many releases were
> > held because maybe there were bugs, except the rate at which they were
> > uncovered was very low.
> >
> > So I think we should have RCs. But we shouldn't have 6 RCs, and we
> > shouldn't keep an RC without a release for 6 months.
> >
> > Mihael
> >
> > On Mon, 2014-12-15 at 15:58 -0600, Yadu Nand Babuji wrote:
> >> Hi Everyone,
> >>
> >> Based on the discussion we had on the Friday meeting, here are some of
> >> the suggested changes to release
> >> strategy and versioning. Please correct me if I got any of the following
> >> wrong.
> >>
> >> Major version will denote language changes that will likely break
> >> backward compatibility.
> >> Minor version increments will indicate feature enhancements.
> >> Sub-minor versions will be assigned after a release has been made, and
> >> will represent bug-fixes.
> >> testing versions for the next release which will be closely following
> >> the repository.
> >> No more RCs
> >>
> >> We will not be using the release-candidate numbering which has put
> >> releases in perpetual limbo, instead
> >> testing releases with no explicit numbering will be used. For example
> >> the next planned release 0.96 would
> >> have a testing branch 0.96-testing. Once planned features have gone in
> >> and are tested, 0.96 will be released,
> >> with bug fixes following it, when identified.
> >>
> >> I will work with the site admins (midway, beagle, LCRC etc..) to ensure
> >> that we have the latest stable release
> >> as well as the testing package for the next release available on the
> >> login-nodes.
> >>
> >> Thanks,
> >> Yadu
> >>
> >> _______________________________________________
> >> Swift-devel mailing list
> >> Swift-devel at ci.uchicago.edu
> >> https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel
> >
>
> _______________________________________________
> Swift-devel mailing list
> Swift-devel at ci.uchicago.edu
> https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/swift-devel/attachments/20141216/90fea454/attachment.html>