I think they're doing it the proper way given the way the package ecosystem works. People who are really involved in the language really need a release candidate to test packages against. Deprecations need to be worked out, all the bugs need to be fixed, and some of the software structures need to be changed to match v0.5. For awhile it's been a moving target. After something works, then all the new packages need to get tagged. This will be a long process which should be handled first, otherwise v0.5 is just a scary wall of deprecations (which causes a lot of performance lags) whenever someone tries to plug into the package ecosystem.
After that change, there will be many different packages and use-cases which are converted for which benchmarks for regressions can be found. In fact, people throughout the Julia's package-sphere will probably pin down the worst performance regressions and make it easy for a v0.5.x release to handle them. I think this is actually a good way for the core devs to utilize help from other devs to more quickly address the issues. Of course it's always nice to just wait for a perfect release and jump on that, but I think that at this point if you're working deeply with the language, you know that part of what your job is helping the language itself. Remember, this is still super alpha! They will probably switch to a much more conservative release schedule when Julia is not alpha. On Friday, July 15, 2016 at 11:43:01 AM UTC-7, David Anthoff wrote: > > 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] <javascript:> [mailto:[email protected] > <javascript:>] *On Behalf Of *Stefan Karpinski > *Sent:* Friday, July 15, 2016 9:34 AM > *To:* Julia Users <[email protected] <javascript:>> > *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] > <javascript:>> 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- <javascript:> > > [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). > > >
