Yeah, I think this just comes down to different needs. I would prefer to see a more extended period between feature freeze and RC that is used to clean up performance problems and some of the things that are currently assigned to the 0.5.x milestone or have the regressions label. Some of the issues that are currently not assigned to the 0.5.0 milestone (like #16047 and #15276) almost certainly mean that I won’t be able to use 0.5.0 and will have to wait until 0.5.1 to make the switch (and if that happens I probably also won’t update my packages until 0.5.x is ready for my daily use). From my point of view, I would prefer a release strategy that doesn’t mimics Microsoft’s old habit where you always had to wait until the first service pack until you could actually use a new version ;) BUT, I can easily see that julia computing/other users have different needs and that the right call here is to do what you seem to plan currently. These are all performance regressions, and they can be a nuisance for some but blocking for others, and then it probably comes down to how many users there are in each category (or what e.g. the paying customers want). I would encourage other users to weigh in on this, might be helpful for the core team to get more perspectives from the wider user base on this question.
My other suggestion is purely procedural on how to handle issues. I think it would be great if there was one clear signal that the core team looked at an issue and decided it is not release-blocking for 0.5.0. I think the 0.5.x milestone is exactly that, right? But there are lots of issues that have neither the 0.5.0 nor the 0.5.x milestone attached, and from my point of view it is unclear whether they have been considered and whether a decision has been made. For example, at some point I asked in #15276 whether it should get a 0.5 label. Jeff responded that every issue tagged “regression” will get attention before 0.5-final. It would simply be great if the core team somehow marked issue that then got that attention. As #15276 stands right now, I got a message saying “we will triage this”, but I never got a message what the triage decision was. The suggestion here is very simple: Try to find some way to communicate back to the larger user base that a triage decision has been made for a given issue. There should be some way to tell whether an issue is awaiting triage or triage has been made (in the negative). A really simple way to do this seems this: 1) issue has no milestone attached => triage decision has not been made, 2) issue is attached to a milestone => triage decision has been made. From: [email protected] [mailto:[email protected]] On Behalf Of Stefan Karpinski Sent: Friday, July 15, 2016 9:34 AM To: Julia Users <[email protected]> Subject: Re: [julia-users] ANN: steps towards 0.5.0 release [candidates] 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] <mailto:[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:[email protected]> > [mailto:julia- > [email protected] <mailto:[email protected]> ] On Behalf Of Keno > Fischer > Sent: Thursday, July 14, 2016 11:18 AM > To: [email protected] <mailto:[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] > <mailto:[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]> > > [mailto:[email protected]] On Behalf Of David Anthoff > > Sent: Thursday, July 14, 2016 11:04 AM > > To: [email protected] <mailto:[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]> > > [mailto:[email protected]] On Behalf Of David Anthoff > > Sent: Thursday, July 14, 2016 10:58 AM > > To: [email protected] <mailto:[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]> > > [mailto:[email protected]] On Behalf Of Tony Kelman > > Sent: Thursday, July 14, 2016 10:25 AM > > To: julia-news <[email protected] > > <mailto:[email protected]> > > > Cc: Julia Users <[email protected] > > <mailto:[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).
