It's a bit odd for there to be simultaneous complaints about 0.4 being unstable (ie under rapid development) and not going anywhere. It's been, what, 13 years since the plans to release Perl 6 were announced? Seems a bit early to worry about that kind of problem a couple of months after the last significant release of Julia. If 0.4 isn't out by 2020 we can start to worry.
> On Sep 26, 2014, at 10:12 AM, John Myles White <[email protected]> > wrote: > > Hans, > > The tone of your e-mail is a little odd in my opinion. It seems to imply > distrust and even possibly anger for a project that would be substantially > better served by participating actively in the issue discussions that Tim > Holy discussed. I don't think anyone who's following 0.4's progress would > ever believe that 0.4 is not on track. > > -- John > >> On Sep 26, 2014, at 3:30 AM, Hans W Borchers <[email protected]> wrote: >> >> Ivar, >> >> thanks for this clarification; I was really under the impression that -- >> like >> for Perl and other projects -- I might never ever again hear from a Julia >> 0.4 >> version. >> >> A question I asked got buried in another thread and never answered, so I'd >> like >> to repeat it here: >> >> Will the NEWS.md file immediately document the (disruptive or >> non-disruptive) >> changes? That would be very helpful, even if the change is withdrawn later >> on. >> Also, every NEWS entry could include a date to make it easier to follow the >> development. >> >> By the way, I am a bit worried about some of the names that seem to come up >> in a >> next version of Julia. For example, 'Nullable' or 'NullableArray' sound >> strange >> for me in a technical computing environment. >> >> >>> On Friday, September 26, 2014 9:19:37 AM UTC+2, Ivar Nesje wrote: >>> I think this is a too strong statement. There are definitely happening a >>> lot on the master (0.4-dev) branch, but it should be quite usable even >>> without reading the majority of Github issues. The more users we have, the >>> earlier concerns is raised, and the earlier we can fix them and prepare for >>> the final release. You should definitely avoid master on any project with a >>> deadline tough. >
