https://en.wikipedia.org/wiki/Software_release_life_cycle#Release_candidate:
A release candidate (RC) is a beta version with potential to be a final > product, which is ready to release unless significant bugs emerge. In this > stage of product stabilization, all product features have been designed, > coded and tested through one or more beta cycles with no known > showstopper-class bugs. This is exactly how we use the term: a release candidate is a version that could be the release as long as no major bugs show up in the following week; if such bugs do become evident, we fix them and make a new RC a week later, including those fixes. This repeats until there's an RC that doesn't have new bugs, at which point that RC becomes the release. Objections here seem to stem from the fact that the release has a set of known, non-critical bugs, but that's a completely standard thing to do in real-world software releases. Every project has different criteria for what constitutes a release-blocking bug and what doesn't: the 0.5.x milestone <https://github.com/JuliaLang/julia/milestone/21> is our list of non-critical known issues for the 0.5 release – each of them has been considered and deemed not to be a show stopper. On Fri, Jul 15, 2016 at 5:36 AM, Sisyphuss <[email protected]> wrote: > It seems to me that it is the same terminology (RC) as *Battle for > Wesnoth.* > > > On Friday, July 15, 2016 at 10:37:19 AM UTC+2, Scott Jones wrote: >> >> I agree, and it does seem there is a bit of a problem with the >> nomenclature that the Julia team is using, which doesn't match industry >> wide practice. >> At least the first Julia release candidate is really just a beta release >> (i.e. after a feature freeze and branch off of current development), as it >> is known that it isn't really ready for release, >> and that known bugs/regressions are still being worked on. >> >> Subsequent RCs may actually meet the definition of a release candidate. >> >> On Thursday, July 14, 2016 at 8:34:21 PM UTC+2, David Anthoff wrote: >>> >>> So what you intend to call "release candidate" is a feature complete >>> build, with a list of known bugs that the core team still intends to fix >>> before a 0.5.0 release? I.e. in fact the first "release candidate" will not >>> be a candidate for a release, because of a known list of things that still >>> need to be fixed? I don't understand why you wouldn't just call that a >>> "beta", that seems the more common way to designate a build like that, >>> seems to much better indicate what that build is. But if you do want to >>> call it RC, then please make sure to communicate to the wider user group >>> that this build is actually not one that you might declare finished. And >>> then once you have a RC that is a true candidate for a release, please also >>> let us know. For me as a user and package developer, I do want to know >>> whether you think a given build is completely done or not. >>> >>> I think the more important question though is, where are you tracking >>> the bugs/regressions that need to be fixed before a 0.5.0 release (at >>> whatever stage of the process)? >>> >>> > -----Original Message----- >>> > From: [email protected] [mailto:julia- >>> > [email protected]] On Behalf Of Keno Fischer >>> > Sent: Thursday, July 14, 2016 11:18 AM >>> > To: [email protected] >>> > Subject: Re: [julia-users] ANN: steps towards 0.5.0 release >>> [candidates] >>> > >>> > Anything that's not on the milestone right now will not be in the RC >>> (other >>> > than the cleanup tasks). >>> > The RC is there so that people can start fixing packages against 0.5, >>> without >>> > having to worry about having to do it again once the release is out. >>> We'll of >>> > course continue cleaning up and working on performance regressions, >>> but >>> > we do need to work towards a release, so we can't block the RC on >>> those. >>> > >>> > On Thu, Jul 14, 2016 at 2:14 PM, David Anthoff <[email protected]> >>> > wrote: >>> > > This is fun ;) >>> > > >>> > > >>> > > >>> > > 7 “needs-tests” issues that haven’t been assigned to any milestone. >>> 7 >>> > > “needs-docs” issue with no milestone assigned. 4 “heisebugs” with no >>> > > milestone attached, one with a “priority” label. >>> > > >>> > > >>> > > >>> > > Just by looking at any of these it is not clear whether they have >>> been >>> > > triaged for 0.5.0, and if so, what the decision was. The main >>> problem >>> > > will all of these seems to be that it is unclear whether a) no one >>> has >>> > > decided about inclusion in 0.5.0 yet, or b) someone decided that >>> this >>> > > would not go into 0.5.0. I think the milestone suggestion below >>> would >>> > > allow a pretty easy management of that information. >>> > > >>> > > >>> > > >>> > > From: [email protected] >>> > > [mailto:[email protected]] On Behalf Of David Anthoff >>> > > Sent: Thursday, July 14, 2016 11:04 AM >>> > > To: [email protected] >>> > > Subject: RE: [julia-users] ANN: steps towards 0.5.0 release >>> > > [candidates] >>> > > >>> > > >>> > > >>> > > There are also 82 bugs that have no milestone assigned. Have these >>> all >>> > > been triaged for 0.5.0 inclusion and it was decided that none of >>> those >>> > > need to be fixed for 0.5.0? If so, how is that recorded in the issue >>> > > tracker? Might make sense to have another milestone named “post >>> 0.5.0” >>> > > that simply indicates that someone from the core team made sure an >>> > > issue doesn’t have to be fixed for 0.5.0, but no other scheduling >>> > > decision has been made about that issue. >>> > > >>> > > >>> > > >>> > > From: [email protected] >>> > > [mailto:[email protected]] On Behalf Of David Anthoff >>> > > Sent: Thursday, July 14, 2016 10:58 AM >>> > > To: [email protected] >>> > > Subject: RE: [julia-users] ANN: steps towards 0.5.0 release >>> > > [candidates] >>> > > >>> > > >>> > > >>> > > +100 to having a release plan like this! >>> > > >>> > > >>> > > >>> > > There are 28 open regressions, I assume/hope those will be taken >>> care >>> > > of before RC1? I.e. after feature freeze, but before RC, right? >>> > > >>> > > >>> > > >>> > > There are 22 open issues assigned to the 0.5.x milestone. The >>> > > description for that one says “Bugs to fix in the 0.5.0 or 0.5.x >>> > > timeframe”. Might be a good idea to make a call on each of these and >>> > > decide which of those have to be fixed for 0.5.0 (in which case they >>> > > should be fixed before RC1) and which will go into 0.5.1. >>> > > >>> > > >>> > > >>> > > Here is one idea on how to handle this in terms of logistics: rename >>> > > the >>> > > 0.5.0 milestone to “0.5.0-beta” (or “0.5.0-feature-freeze” or >>> > > something like that). These are the items that need to get done >>> before the >>> > feature freeze. >>> > > Create a new milestone “0.5.0-RC1”, and assign those issues that >>> need >>> > > to be fixed before RC to that milestone. I guess that should be most >>> > > issues with a “regression” label (but maybe not all, seems possible >>> > > that you decide to fix some of the regressions later), and some >>> subset >>> > > of the issues with the 0.5.x label. If needed, create more RC >>> milestones as >>> > things go on, i.e. >>> > > “0.5.0-RC2” etc. Change the description of the 0.5.x milestone to >>> say, >>> > > “Things to do in a 0.5.x release”, and anything assigned to that >>> > > milestone will definitely not be done for 0.5.0. >>> > > >>> > > >>> > > >>> > > Very exciting to see 0.5 come to a close!! >>> > > >>> > > >>> > > >>> > > Cheers, >>> > > >>> > > David >>> > > >>> > > >>> > > >>> > > From: [email protected] >>> > > [mailto:[email protected]] On Behalf Of Tony Kelman >>> > > Sent: Thursday, July 14, 2016 10:25 AM >>> > > To: julia-news <[email protected]> >>> > > Cc: Julia Users <[email protected]> >>> > > Subject: [julia-users] ANN: steps towards 0.5.0 release [candidates] >>> > > >>> > > >>> > > >>> > > See https://github.com/JuliaLang/julia/issues/17418 for how this >>> > > process is going to go. Please keep any discussion on that github >>> > > issue focused so the noise level stays manageable. If you have any >>> > > questions or comments, you can ask them here (don't cc julia-news if >>> > > you do so though, that list is intended to be low-volume). >>> >>
