While it certainly would be ideal to always get perfect feedback on issues, it should be taken into account that Julia is a large piece of software and that only finite resources are working on it.
Regarding when to release I think the core team just makes it right. During 0.3 we had effectively a rolling release which was suboptimal for package ecosystem. Better make more defined releases. Currently it seems that one release per year is a good cycle. Tobi Am Freitag, 15. Juli 2016 20:43:01 UTC+2 schrieb David Anthoff: > > 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). > > >
