0.2 release notes

[ViralBShah]

I am starting this issue for two reasons - to start collecting items for Release Notes for 0.2. This will be continuously updated as the discussion progresses.

Current date for the 0.2 milestone is April 5.

Release Notes:

1. Immutable types (#13)
2. Functions that were deprecated in 0.1 are removed (include the list)
3. varm, stdm (#2265)
4. getindex, setindex! (#1484, #907)
5. Linear algebra updates (#2212)
6. Updates to the package manager
7. Removal of extras (#2422)
8. Named arguments (#485)
9. Optional positional argument syntax (#1817)
10. Explicit relative importing (#2375)

[mlubin]

Might want to mention the change in the Expr syntax also.

[JeffBezanson]

Also check the bottom of base/deprecated.jl.

There's no need to list 0.2 dependencies in here; there's a milestone for that. And that list of 43 is looking pretty hopeless.

[wlbksy]

[i18n] beginnings of i18n support example of usage: https://github.com/JuliaLang/julia/issues/2498#issuecomment-14600296

[stevengj]

• Support optional RTLD flags in dlopen (#2380)
• unsafe_pointer_to_objref (#2468) and pointer_from_objref (#2515)
• Rename :typed-dict and other non-quotable Expr symbols to :typed_dict etcetera (#2389)

[JeffBezanson]

• indented multi-line strings
• Other new functions: readandwrite, versioninfo, methodswith, logdet
• names for C-compatible types: Cchar, Clong, etc.

[mlubin]

Were keyword args bumped to 0.3?

[JeffBezanson]

It might be possible to put keyword args in 0.2, but the whole problem is what to do with the other 40 issues.

[johnmyleswhite]

I think that officially supporting keyword args in 0.2 would be huge.

[mlubin]

+1. I think many people would be fine with pushing the release back a week if needed because it's a huge feature that will change (improve) how libraries are written and used. Up to you guys though.

[ViralBShah]

I feel that pushing 0.2 to a later release date to accommodate keyword arguments and resulting API changes is worthwhile. These changes become a lot more difficult to make later.

[ViralBShah]

As for the 40 open issues, people just need to chip away at them. Can we have everyone look at the list and pick whichever ones they can fix, so that all issues have an owner who will fix them?

[johnmyleswhite]

I can clean up logdet and add documentation for it.

[ViralBShah]

The toughest part of the open issues is all the various package related issues - @StefanKarpinski and @pao will have to help us out on figuring out what all can be done by 0.2. It would be nice if the packages can stabilize for 0.2, and we can have all package maintainers update their packages to be compatible with 0.2. We may perhaps want to have a one week gap between tagging and announcing 0.2.

The rest of the issues are reasonably easy to tackle over the next 2 weeks, and we may have to push a couple out to 0.3. I have claimed a number of them.

[StefanKarpinski]

When did we even pick a date for 0.2? I don't recall doing that.

On Wed, Mar 20, 2013 at 11:54 PM, Viral B. Shah notifications@github.comwrote:

The toughest part of the open issues is all the various package related issues - @StefanKarpinski https://github.com/StefanKarpinski and @paohttps://github.com/paowill have to help us out on figuring out what all can be done by 0.2. It would be nice if the packages can stabilize for 0.2, and we can have all package maintainers update their packages to be compatible with 0.2. We may perhaps want to have a one week gap between tagging and announcing 0.2.

The rest of the issues are reasonably easy to tackle over the next 2 weeks, and we may have to push a couple out to 0.3. I have claimed a number of them.

— Reply to this email directly or view it on GitHubhttps://github.com/JuliaLang/julia/issues/2581#issuecomment-15218251 .

[ViralBShah]

It has kind of always been there. Someone surely picked it!

[JeffBezanson]

current requested fix rate: 3 issues/day actual fix rate: 0/day estimated finish: never

[vtjnash]

The purpose of tagging 0.2 is to be able to generate updated, tagged binaries for windows (and other platforms). As such, I picked a monthly release schedule. My hope was that this would correspond to a reasonable period a time to get some work done between binaries, without letting binaries get too behind (since it is painful to compile from source sometimes). One month also roughly corresponded to the approximate period of time between binary releases last fall.

Also, Windows 64 binaries may be included in 0.2 (probably with beta status, until they get more usage)

[diegozea]

Due date for 0.2 is today. But Ubuntu 13.04 is launched on April 25. Would be great a next stable release of Julia (0.2) for that date. In order people can starting using Julia 0.1 with Ubuntu... and after look on Julia lang web page maybe opting for update to 0.2

[diegozea]

[ Keyword args, Immutable types and support for new packages are good options for choose make an update ]

[andrioni]

Unfortunately it won't be possible to target Ubuntu 13.04, as the feature freeze happened on March 7th.

[ViralBShah]

Keyword args will have to settle for a while, as the APIs change to accommodate it. I am guessing that we should give it a month to shake things out.

Ubuntu 13.04 will ship with Julia 0.1.2. We will have PPAs for 0.2.

[andrioni]

Viral, this means 0.2 will be delayed for around another month, as keyword args are already in the main tree? I want to know if I should bump a version in my packages to use keyword arguments (and then target the current HEAD and possibly 0.3) or I can already use them in the version targeting Julia v0.2.

[ViralBShah]

I think you should be fine targeting Julia v0.2 for keyword argument support.

One thing we should do this time around is make sure that packages are ready for v0.2 before v0.2 is officially released.

[vtjnash]

Can someone (probably @JeffBezanson) go ahead and tag a good commit as v0.2? Once that is done, I'll confirm functionality on windows and put up new binaries.

[JeffBezanson]

I don't think we're ready to tag. This was an arbitrarily-chosen day. There are probably a few more things we'd like to get in. But, I don't know if we will fix all 29 issues. Let's try to make the 0.2 milestone reflect what we will actually do.

[ViralBShah]

Although we are not ready in any way for a 0.2 milestone, I think targeting May 1 as a target release date may be a good idea. I think the major features for 0.2 are in, but a lot more needs to be done on APIs due to kw args, general stability, package compatibility, etc.

[vtjnash]

I don't mind just bumping these issues to 0.3, but I would really like to release a new windows binary soon (my goal is monthly, to keep pace with changes in julia -- the release notes already show significant additions). Possibly the tag should be the commit before kw args?

[pao]

Last time we tried to hit an arbitrary date we rushed in a bunch of stuff and ended up with the Pkg mess we have now. If we want to call something "0.2 beta" so the Windows binaries can look more official, fine, but given the v0.1 disaster (yay broken stuff we have to support for who knows how long because we're in a distro) I can't figure out why this is a good idea.

[mlubin]

Why not release snapshot binaries for windows?

[StefanKarpinski]

The whole idea of forcing releases because binaries need to be updated is broken – as @pao points out, this didn't go very well last time, let's not do it again. Even though the 0.1 release was much smoother than 0.1.1 and 0.1.2, it wasn't exactly perfect. We should tag a release candidate and let it simmer for a while before deciding that it's ready to be a release. None of this is compatible with monthly binaries. So, yes, there should be monthly binary snapshots instead and 0.2 will be tagged when it's ready to be tagged.

[vtjnash]

What if we were to declare that odd numbered releases (e.g. v0.1) are supported for 2 years, while even numbered releases (e.g. v0.2) are supported for 4 months? Thus, I can still have a version number branch for a new binary, but not require the same level of effort in preparing it. (in this scheme, we would skip most odd numbers, since even-numbered releases would be monthly, but odd numbered releases would be every 6 months)

[pao]

(e.g. v0.1) are supported for 2 years

Are you volunteering to be that maintainer? I think the quicker we forget that v0.1.x happened the better.

[StefanKarpinski]

Ouch. But yes, I agree. I certainly don't think it makes sense to maintain 0.x versions past 1.0.

[vtjnash]

I hadn't realized that ubuntu 13.04 support changed to 9 months (https://wiki.ubuntu.com/LTS), so maybe 2 years is a bit overkill -- more like 1 year?

[andrioni]

Also, there's no point in maintaing these early versions with few packages. For example, almost all packages already use immutable, making them unrunnable on 0.1, and probably we'll have many more syntax changes in the months/years to come. For example, Rust has just had lots of syntax breaking on 0.6.

[ViralBShah]

I think we should get into a feature freeze for 0.2. Is there a good reason not to do this? 0.1 was a good exercise to go through. Let's make 0.2 smoother. Release candidates will help ensure that a good release is put out.

[quinnj]

With the windows binary being my main platform, I'd prefer to wait until we have at least immutable and keyword arguments stable enough for a new binary. Those are big enough changes that having access to them is important in updating packages and reworking code (rather than having another binary immediately that was pre these features).

Definitely excited to get these features though! Thanks for the work everyone!

[aviks]

I'd add my vote for doing pre-release binaries for windows. We can number them as 0.2-pre, and release the official 0.2 binary after 0.2 is tagged in git. This way, we will get some usage and feedback on bleeding edge features before we freeze the release.

[ViralBShah]

Yes, definitely a good idea.

[JeffBezanson]

Where should we put release notes? Should we add a NEWS file?

[jiahao]

More linear algebra fixes and eigensolver hooks for SymTridiagonal, Tridiagonal and Bidiagonal matrix types (#2606, #2608, #2609, #2611, #2678, #2713, #2720, #2725) Documentation for writing packages (#2714, 2769, #2791) and linear algebra (#2807)

[ViralBShah]

I have updated the milestone dates. It looks like we should be able to do new releases every three months. I have updated the dates with 0.2 being targeted for May 15 and 0.3 for Aug 15.

Are we expecting any major new features to land in this timeframe for May 15? If not, we should probably announce a feature freeze this week, and work towards a release by May 15.

We should also tag a couple of release candidates this time (say around May 1 and May 7), so that packages can be up-to-date with the release when it is announced.

@vtjnash Thanks for pushing on the release dates. This is much needed! Given this, let's prioritize on issues we should absolutely fix for 0.2, and those that can be pushed to 0.3.

[ViralBShah]

We should probably do a couple of IRC sprints too, like we did for the last release - but we should certainly not rush the release itself this time.

[jiahao]

Not really a feature per se, but it's really nice to showcase also the existing translation efforts into Chinese, Portuguese and Spanish as well.

[wlbksy]

Call for monthly release/pre-release/feature binary.

[ViralBShah]

Monthly release is too stressful. However, we can certainly have monthly binaries. I can upload a new mac binary. @vtjnash Can you upload a new Windows binary?

[stevengj]

• erfinv and erfcinv functions (#2987).

[andrioni]

MPFR-based BigFloats (#2814).

[ViralBShah]

priority queues (https://github.com/JuliaLang/julia/pull/2920)

[ViralBShah]

@amitmurthy @loladiro - Should the FDWatcher stuff be included in here? If so, could you please link the relevant pull request / issue / commit?