[Swift-devel] Release strategy

[Mihael Hategan]

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