Thanks for making this a new thread, it was getting off-topic. Jeff's probably very busily working on https://github.com/JuliaLang/julia/issues/8839 right now and might not have plans that extend too far beyond that, but you'll have to ask him. I think you'll get different answers to these questions from everyone you ask - if there's a centralized grand plan that only the core team (wherever you want to draw that line) knows, they probably would have let everyone know by now.
Most of us are playing it by ear and enjoying it as we go. Julia's quite usable now, otherwise we wouldn't be here. It will continue to get better, people recognize the current problems and are working on them. As John said though there will be future problems that we don't know about yet. Declaring 1.0 means not expecting any breaking changes for at least a few minor versions, I feel like that would require more decoupling of the core language from the standard library (or minimizing the number of features we include in the standard library) as library features will need to continue evolving in possibly breaking ways even after the core language can be called ready for 1.0. There is a general theme of wanting to shrink the core that many of us would like to work towards over time, and in a parallel effort trying to make the installation experience for commonly-used packages better. And we're actually being stricter than semver requires for 0.x.y version numbers, I don't see any reason to rush things or make unreliable long-term predictions. On Wednesday, December 10, 2014 4:45:18 PM UTC-8, David Anthoff wrote: > > I hear you, and I didn’t think much before sending my email. Couple of > points: > > > > I totally agree this should certainly not be on the homepage. I also agree > that there is no need for a detailed schedule, deadlines or anything like > that. I think the only thing that would be immensely helpful at least for > me is just a very high level idea of what the core team is thinking about a > roadmap/timing. Do you expect a 1.0 more in 10 years, or more in 1 year? Do > you right now expect there to be a 0.5, 0.6, or many more releases before a > 1.0? My gut guess is that the core team has an idea about those kinds of > questions, and it would be great if you could share that kind of stuff from > time to time. Maybe one idea here would be that the core team just sends > out a brief email after a major release what the current thinking is about > the next version and the road to 1.0? Such an email could be fuzzy and > non-committal if the plans are fuzzy, but that in itself would also be > valuable information for us users. > > > > I am following the issue tracker and am subscribed to the email lists, and > I don’t get any sense/picture about those kind of high level questions from > those sources. > > > > Cheers, > > David > > > > *From:* julia...@googlegroups.com <javascript:> [mailto: > julia...@googlegroups.com <javascript:>] *On Behalf Of *Tony Kelman > *Sent:* Wednesday, December 10, 2014 4:31 PM > *To:* julia...@googlegroups.com <javascript:> > *Subject:* Re: [julia-users] Re: home page content > > > > -1 on trying to put plans, schedule, roadmap on the website. "This week in > Julia" was a great contribution to the community but evidently took more > effort than Matt had time to keep up with. > > > > New features get developed as the PR's for them get worked on and > finished. You can subscribe to just the subset of issues/PR's for things > you (along with everyone else) are eagerly awaiting. Better yet, help with > testing and code review if you can. > > > > We have been doing a good job of monthly backport bugfix releases, we > should be able to continue doing that. But 0.4 is still unstable and has > several big-ticket items still open and being worked on (check the > milestones on github). It's too early to try to make time estimates, if > people are impatient and want a release sooner it's not going to be > possible without punting on a number of targeted features and pushing them > back to 0.5 or later. > > > > On Wednesday, December 10, 2014 1:58:52 PM UTC-8, Randy Zwitch wrote: > > I think it would please everyone if you moved daily televised scrums. > > > > > On Wednesday, December 10, 2014 4:53:50 PM UTC-5, John Myles White wrote: > > Stefan, I shared your moment of terror about the idea of posting plans > (essentially all of which will be invalidated) to the home page. > > > > Although it's huge volume of e-mail, I do feel like people who want to > keep up with new developments in Julia should try to subscribe to the issue > tracker and watch decisions get made in real time. It's a large increase in > workload to ask people to both do work on Julia and write up regular > reports about the work. > > > > -- John > > > > On Dec 10, 2014, at 1:48 PM, Stefan Karpinski <ste...@karpinski.org> > wrote: > > > > I have to say the concept of putting plans up on the home page fills me > with dread. That means I have update the home page while I'm planning > things and as that plan changes and then do the work and then document it. > It's hard enough to actually do the work. > > > > On Wed, Dec 10, 2014 at 4:44 PM, David Anthoff <ant...@berkeley.edu> > wrote: > > +1 on that! Even vague plans that are subject to change would be great to > have. > > > > *From:* julia...@googlegroups.com [mailto:julia...@googlegroups.com] *On > Behalf Of *Christian Peel > *Sent:* Wednesday, December 10, 2014 10:15 AM > *To:* julia...@googlegroups.com > *Subject:* Re: [julia-users] Re: home page content > > > > One thing that I would very much appreciate is some kind of development > schedule. For example > - Some kind of general roadmap > - a plan for when 0.4 and future releases will come > - Any plans to switch to a regular schedule? (yearly, six > months, ...) > - What features remain before a 1.0 release? > - When will following arrive? > > faster compilation > > pre-compiled modules > > Interactive debugging; line numbers for all errors > > Automatic reload on file modification. > > Solving P=NP > > I know that it's tough to make such a schedule, but anything that you can > provide would be helpful. Also, I'd be happy for something like a weekly > update; or a weekly blog post to help those who don't peruse this group in > depth each day. > > Thanks! > > Chris > > On Wednesday, December 10, 2014 5:41:35 AM UTC-8, Tamas Papp wrote: > > From the discussion, it looks like that homepages for programming > languages (and realed projects) serve two purposes: > > A. provide resources for the existing users (links to mailing lists, > package directories, documentation, etc) > > B. provide information for potential new users (showcasing features of > the language, links to tutorials). > > Given that space on the very front page is constrained (in the soft > sense: no one wants pages that go on and on any more), I think that > deciding on a balance between A and B would be a good way to focus the > discussion. > > Once we have decided that, we can shamelessly copy good practices. > > For example, > > 1. the R website emphasizes content for existing users (in a non-flashy > way that I am OK with), with very little material for new users, > > 2. about 1/3 of the middle bar on > https://www.haskell.org/haskellwiki/Haskell is for new users > (explanations/tutorials/etc), the 1/3 is for existing users (specs, > libraries), and the final 1/3 is for both (forums, wiki, etc), > > 3. http://new-www.haskell.org/ is mostly caters to potential new users > ("see how great this language is"), > > 4. the content of clojure.org is similarly for potential new users, > while the sidebar has links for existing users. > > Best, > > Tamas > > On Wed, Dec 10 2014, Hans W Borchers <hwbor...@gmail.com> wrote: > > > Look at the R home page. R is one of the most popular languages, and > esp. so > > for statistical and computational applications. A programming language > does > > not need bloated home pages. > > > > I like the old Haskell home page much more than the new one. The new one > > has > > large, uninformative background pictures and not much information in a > > small > > and readable view. The HaskellWiki front page was much better in that. > It > > may > > not even be decided which version will win. > > > > [Clojure])http://clojure.org/) has a nice, simple and informative home > > page, > > while [Scala](http://www.scala-lang.org/) has overdone it like the new > > Haskell. For other approaches see the [Nim](http://nimrod-lang.org/) - > > formerly 'Nimrod' - and [Nemerle](http://nemerle.org/) home pages. > > > > In the end I feel the condensed form of the Python home page will > attract > > more interest, for example with 'latest news' and 'upcoming events' on > the > > first page.This gives the impression of a lively and engaged community. > > > > > > On Wednesday, December 10, 2014 11:23:37 AM UTC+1, Tim Holy wrote: > >> > >> I like the Haskell one better than the Rust one. > >> > >> --Tim > >> > >> > > > > > >
