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 (implement immutable types #13)
2. Functions that were deprecated in 0.1 are removed (include the list)
3. varm, stdm (mean function on dimension #2265)
4. getindex, setindex! (rename ref etc. to something less likely to conflict #1484, consider consistently using ! for mutating functions #907)
5. Linear algebra updates (WIP: Linear Algebra bikeshedding #2212)
6. Updates to the package manager
7. Removal of extras (Plan for removing extras #2422)
8. Named arguments (keyword arguments #485)
9. Optional positional argument syntax (support C++ style default arguments? #1817)
10. Explicit relative importing (import/using search order? #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: #2498 (comment)

[stevengj]

• Support optional RTLD flags in dlopen (add optional RTLD flags argument to dlopen, fixes issue #2312 #2380)
• unsafe_pointer_to_objref (RFC: add unsafe_pointer_to_any (fixes #2458) #2468) and pointer_from_objref (RFC: extend unsafe_assign to work for any isbits type, add pointer_from_objref #2515)
• Rename :typed-dict and other non-quotable Expr symbols to :typed_dict etcetera (Expr should use quotable symbols only #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@git.luolix.topwrote:

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//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?

[JeffBezanson]

I figured it would typically be called NEWS.md

[staticfloat]

Or even CHANGELOG.md. (Man, the bikeshed principle really is true, isn't it!)

[stevengj]

Usually, the ChangeLog would be a dump of git log, whereas NEWS would a human-written summary.

[staticfloat]

That's going to be a heck of a read. :) As long as we have a human-written summary somewhere, I don't care if we dump ~3K commits into a file. It'll be just like a dissertation; a document chronicling an amazing amount of work, that very few will understand, and even fewer will ever read.

[StefanKarpinski]

Let's skip the changelog – that's an artifact of an era before distributed version control gave everyone easy access to the full revision history.

[stevengj]

readbytes and readbytes! functions (#3878)

writeable renamed to writable (#3874), and isreadable/iswritable functions added for more IO types (#3872)

[ViralBShah]

I think a concise release notes that includes major features and changes is greatly useful. For Example, see LLVM release notes. We certainly do not need a changelog and for that, the commit history suffices.

[stevengj]

flush_cstdio function (#3949)

Multimedia I/O API (display, writemime, etcetera): #3932

[StefanKarpinski]

New variable bindings on each for loop and comprehension iteration: #1571.

[andrioni]

Rounding modes for floating point arithmetic: #3149

[stevengj]

Would be better for people to submit pull requests against the NEWS file rather than in this issue...

[JeffBezanson]

Very true.

[JeffBezanson]

NEWS is in good shape now and we are nearing feature freeze so I think this is done.

[ViralBShah]

Pinging everyone here to take a quick look at NEWS.md and add any updates in the last two months, which may deserve a mention.

[ivarne]

For those who like to click on links: https://github.com/JuliaLang/julia/blob/master/NEWS.md

[vtjnash]

win64 support
improved backtraces on windows and mac

[timholy]

If this is intended as the main way to announce the changes, can I suggest starting out with a paragraph that might be something like this:

The 0.2 release brings improvements to many areas of Julia. Among the
most visible changes are keyword arguments to functions, immutable
types, support for 64-bit Windows, a redesigned and polished package
manager, a multimedia interface supporting usage of Julia in IPython,
a built-in profiler, and major improvements to Julia's I/O and
parallel capabilities. These changes are accompanied by many others
adding new features, enhancing the library's consistency, and
improving performance. While not part of Julia proper, the package
ecosystem has also grown and matured considerably since the 0.1
release. See below for more information about the long list of
changes that improve Julia's usability and performance.

I hate to pick out a few items (so many awesome changes!), and I encourage others to redesign the balance here, but something more than a list seems warranted for such a major achievement!

[ViralBShah]

+1

[timholy]

• Improved handling of SubArrays (01fe6bc, stride behaves differently on subarrays and arrays #4412, sub(sub(A,...),...) violates type-stability of range indexes #4284, 50f37f1, beee4e2, SubArray bounds checking (or not): bug or feature? #4044, 8bfb697, print_matrix is broken for SubArrays #3697, getindex(S::SubArray{T,2}, i::Integer) allocates memory when it probably shouldn't #3790, e392ec1, c84a058, 7eb374e, SubArray indexing with (integer valued) floats is broken #3148, Problems with subarray indexing for >2-dimensional arrays. #2844, slice leads to broken indexing #2644)
• New convenience functions in graphics API

Also, perhaps somewhere prominent we should mention documentation improvements, which have been numerous. These include the contributions of many developers and users.

[ViralBShah]

I am reopening this issue temporarily to make sure that any new discussion that needs to be captured in NEWS.md is done before release.

[timholy]

I tweaked and pushed that paragraph, and also collected the specifics mentioned so far.

[StefanKarpinski]

I spent some time cleaning up the NEWS file last night. It's looking pretty solid at this point.

[staticfloat]

Are we good to cut an RC3 now? I don't see much on my end to put into NEWS.md now. (Thanks for that intro paragraph, Tim!)

[StefanKarpinski]

There's Ingmar Schuster's segfault bug that Jeff is working on and the type inference bug that Jameson opened today.

[StefanKarpinski]

Actually, the former is already taken care of: ceeade0. Now it's just the type conversion (not inference) business: #4681.

[timholy]

Jeff seems to fix issues about as fast as they can be enumerated.