In what version is Julia supposed to "mature"?

[Pileas]

Greetings,

I have been following the development of Julia for sometime now and I am really thrilled to know that you guys have reached version 0.3.11.

To my understanding sometime in the near future you will release the new version 0.4.0., a version that it is supposed to bring many changes. 

My question is simple: when is Julia expected to "mature", so that a "universal" (more or less) documentation (or maybe more thorough books than those that exist by now) will follow and less bug fixed will be needed?

I wish you the best! 

[Stefan Karpinski]

Version 1.0 will be released around this time next year.

[Kevin Squire]

Stefan, are you trolling again?  ;-P

http://julialang.org/blog/2012/02/why-we-created-julia/

[Stefan Karpinski]

That's literally the only part of that post that I would change :-)

But no, I'm not trolling, 1.0 should be out next year. Predicting down to the month – or even quarter – is hard, but that's what I think we're looking at. I'll post a 1.0 roadmap issue soon.

[Tony Kelman]

I'm with Kevin, having followed development (too) closely for the last year and a half I find the prospect of 1.0 any time during 2016 totally ridiculous and unrelealistic. Unless you fully anticipate releasing 2.0 some time in 2017.

[Stefan Karpinski]

Doing more frequent major releases than has been traditional for programming languages strikes me as not a terrible idea, honestly.

[Tony Kelman]

Actually considering that we've been more strict about version discipline than absolutely required by semver for 0.x.y, maybe we could pull a GCC and just start treating major number the way we've been treating minor. It might not be all that different, except we'd be able to do the "backporting features" thing and have a very good way of dealing with it. So I retract my incredulity.

[Stefan Karpinski]

I do believe that other languages have not really followed the semantic versioning specification (can't blame them really since it didn't exist) and have introduced backwards incompatible changes in minor versions. If we're going to follow semver, then we will very likely want to make major releases more often since we will probably have some backwards incompatible changes we want to introduce periodically, even if they're not huge.

[Tony Kelman]

I guess the waters are a little muddied here lately with Rust having recently put such a big emphasis on stability and reaching 1.0, actively telling people not to use the language prior to that point, and seemingly having really high expectations about how long 1.x will last for. They have a much smaller standard library than we do, but I would think trimming ours down to the bare minimum would be necessary before calling the language 1.0. Maybe that could just as well be a 2.0 or 3.0 target instead.

[Tomas Lycken]

There was an interesting discussion on the dev list not long ago about the release schedule of Julia. Although it focused more on timeline and less on version numbering, it touched on several of the topics discussed in this thread as well. We do have some “expectation problems” of our own in the Julia community, for example as Tobi put it in the other thread:

the main issue is in my point that during a dev period feature come in and people start to use the dev branch for regular development. The Compat module is in my opinion made the wrong way around. What currently happens is that unstable features are bypassed into a “released” package landscape.

Julia is an awesome project, and it’s going to be an awesome product when it’s “done”. But currently, we’re in the middle of a phase of development where you cannot expect to accurately predict where we’re going to be in three or six months, much less predict a date for a 1.0 release (after all, it was once said that “we’ve been much more on top of the release process this time” about 0.4, but we’re still falling behind schedule on this one too…). Don’t get me wrong - I think this is totally fine for a project like Julia. We should be experimenting, trying things out and taking the time to make sure the decisions we make are the right ones.

But maybe we should stop expecting to have a production-quality product to play around with.

(On the other hand, Julia programmers will probably always have high expectations, considering Julia’s origins…)

// T

[Eric Forgy]

Great news! :)

[Job van der Zwan]

On Wednesday, 29 July 2015 19:00:38 UTC+2, Tony Kelman wrote:

I guess the waters are a little muddied here lately with Rust having recently put such a big emphasis on stability and reaching 1.0, actively telling people not to use the language prior to that point, and seemingly having really high expectations about how long 1.x will last for. They have a much smaller standard library than we do, but I would think trimming ours down to the bare minimum would be necessary before calling the language 1.0. Maybe that could just as well be a 2.0 or 3.0 target instead. 

Go did the same before. I think it's because both position themselves as systems languages (with slightly different - but both valid - definitions of "systems"). I don't think the need for stability is quite as important for Julia - library maintainers still care of course, but there's not as much infrastructure built on top of Julia that depends on guaranteed stability.

[Tony Kelman]

Hah. Go's definition of "systems" is totally invalid everywhere in the world except inside Google.

We also have nicer syntax macros than either of those languages. Compat might start getting pretty ungainly over time, but we can use REQUIRE to deal with that if the version range ever gets too intractable to support everything within the same set of macros.

[Job van der Zwan]

Let's not turn this into a tribal language pissing contest, please.

[Tom Breloff]

Then what kind of tribal language contest should it be??