100% agreed with Keno. Re: "significant problems with APIs that cannot be fixed later because that would require incompatible breakage" we would very very much like to avoid having to make that kind of change after an RC1, even after feature freeze. So if you're willing to test against the 0.5-dev nightlies / not-quite-feature-frozen master, please do so now and raise issues if you think anything rises to that level! Likewise if you can help with triaging of various labeled / unlabeled issues. I'd consider master to be in an "okay to test against" but not "okay to release" state right now.
Basically unless you're hitting one of the two issues that are currently blocking feature freeze, you should consider latest master as "beta" right now. We shouldn't release an RC1 that we wouldn't be happy with as a final release, but there's a different set of information that we know now vs what we will know after tagging RC1. Re: "where are you tracking the bugs/regressions that need to be fixed before a 0.5.0 release (at whatever stage of the process)" these will be added to the 0.5.0 milestone when identified. That milestone means "blocking the upcoming release candidate." IMO we don't need to create any new milestones here. The 0.5.x milestone means "post 0.5.0, or sooner if we get to it in time"). I don't think we need separate milestones per RC either, since we'll only be doing one at a time. On Thursday, July 14, 2016 at 11:44:57 AM UTC-7, Keno Fischer wrote: > > RC means all the for the release features are done and all bugs that are > absolutely necessary to fix have been fixed. > There are several bugs that would be great to fix, but if they are not on > they milestone they have not been designated as release blocking (meaning > under no circumstances will we make a release without those bugs fixed). As > with past releases, there will be several release candidates as packages > get updated and critical issues get discovered. Examples of critical issues > are crashes, miscompilations, significant problems with APIs that cannot be > fixed later because that would require incompatible breakage. Performance > regressions and suboptimal performance, as much as they need to get fixed > are not release-blocking, because they can be fixed at any time during > the RC period or in a point release. > > On Thu, Jul 14, 2016 at 2:34 PM, David Anthoff <[email protected] > <javascript:>> 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] <javascript:> [mailto:julia- >> <javascript:> >> > [email protected] <javascript:>] On Behalf Of Keno Fischer >> > Sent: Thursday, July 14, 2016 11:18 AM >> > To: [email protected] <javascript:> >> > 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] >> <javascript:>> >> > 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] <javascript:> >> > > [mailto:[email protected] <javascript:>] On Behalf Of David >> Anthoff >> > > Sent: Thursday, July 14, 2016 11:04 AM >> > > To: [email protected] <javascript:> >> > > 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] <javascript:> >> > > [mailto:[email protected] <javascript:>] On Behalf Of David >> Anthoff >> > > Sent: Thursday, July 14, 2016 10:58 AM >> > > To: [email protected] <javascript:> >> > > 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] <javascript:> >> > > [mailto:[email protected] <javascript:>] On Behalf Of Tony >> Kelman >> > > Sent: Thursday, July 14, 2016 10:25 AM >> > > To: julia-news <[email protected] <javascript:>> >> > > Cc: Julia Users <[email protected] <javascript:>> >> > > 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). >> > >
