Sorry, of course you’re right, that’s always been expression syntax—so the depwarn is a little confusing. You just need parens, (:)(3,5).
And if the OP was about overriding it, then it’s:
julia> import Base: :
ERROR: MethodError: no method matching -(::Nothing, ::Nothing)
 (::Colon)(::Nothing, ::Nothing) at ./range.jl:7
 top-level scope at none:0
julia> (:)(::Nothing, ::Nothing) = "hello"
(::Colon) (generic function with 14 methods)
Telling somebody (who we don’t know) to use 0.7 when trying some code (for example from blog) could be felt as strange behavior.
I don’t understand this at all. The point of 0.7 was to help people change their code, but not everyone got the message. If someone comes to you with a problem, how does providing them with the systematic way to figure things out on their own constitute a problem? What, exactly, are you proposing as an alternative?
Publishing 0.7 (nearly) parallel to 1.0 was ugly hack which ignore meaning of deprecation period (period is about time, right?).
Publishing 0.7 nearly parallel to 1.0 was amazing. This is the best kind of deprecation I have ever seen. The deprecation period is from publication of 0.7 until there is some critical 1.0.x or 1.x bugfix or feature you need that fails to get backported to 0.7.
My main minor gripe is the naming of versions, because obviously a lot of people did not get the memo (this question pops up a lot). Also, a lot of new people started on 1.0 before the ecosystem transitioned (you get the publicity for “1.0” only once).
Second, linux distribution support is lacking; for example archlinux used to ship 0.6 only, and now ships 1.0 only. I’d have prefered a similar story to python, where it is clear that different versions are completely different languages and you get all relevant versions you want to install to cooperate (there want to be julia10 and julia06 and julia07 binaries and a symlink /usr/bin/julia to whatever version I want as default). pacman -Syu breaking my code was not nice. I don’t know how other distributions (julia pro? conda? debian? cygwin?) deal with that. I don’t know whether julialang influenced that or provides guidance for distribution, but that could have been handled better (and yes, sure, building it myself and placing symlinks works, but this defies the point of having a distro at all).
First of all I would change wording. Instead of Use julia-0.7 when you have questions like this it would rather say something like it could be useful to use julia-0.7 when you have **more** questions like this.
We could also tell people that useful info they could find in History.md on github.
But if you really want (*) that people have test it in 0.7 maybe we could bundle both version into current install binaries. (or add choice to install both in single step)
Although I agree that many people seem to have missed the v0.7 memo, I think it is important to realize that v0.7 is really only relevant for people who have already used Julia before v0.7, that is in a phase where it was common knowledge that new Julia versions will certainly break things.
Those people aren’t new Julia users. I think it’s ok to treat them like rather established Julia users and just point them to the relevant information without too many words. I don’t think that’s rude in any way but rather efficient.
I don’t really see the point of telling people that they can read more about a project’s history in (surprise!) HISTORY.md.
All these things are obvious/standard, or can be found with negligible effort. Simply restating them leads to infinite regress: from then on, you have to think about the possibility of people not finding the meta-documentation where you pointed them to the documentation.
I think it would be best for future discussion about similar topics if people who had a hard time finding some information despite making a reasonable effort came forward and talked about their experience. This would allow us to improve the documentation where needed.
I only partially agree with this argument that has been raised several times. Other than old users, new users that come from a Matlab background will have (bad) surprises that v0.7 warns about but v1.0 just erros (linspace and repmat come to my mind but I have crossed with other situations).
AFAIK there was no explicit intent to warn Matlab users specifically. This is just accidental and covers a subset of Matlab idioms that were used in Julia initially. Matlab users should benefit from the writeup of differences.
But they were never part of Python. They were part of Julia, and new users get confused when they try to run example code found online.
There might not exist a quick fix, and it will fix itself in time. Or maybe there just needs to be some clearer instructions on the Downloads page. Right now there is, in fact, some text explaining when using v0.7 might be useful. Perhaps that text should just be moved up and highlighted.
I don’t think developers of a language are responsible for external tutorials and example code (except that provided in the documentation). It’s on the authors of those tutorials to specify the version used during the tutorial.
I agree - this would probably solve most questions of “why doesn’t this example from place y work anymore”, but as far as I can tell those are not the majority of questions about this (at least here on Discourse). As far as I can tell, the number of people updating older code and asking about why it doesn’t work anymore far outweigh those just newly learning julia (there might a be a large hidden figure here though). Those would certainly also be served well with a more direct message of “hey, use 0.7” on the download page. Maybe even something like
Updating code from before Julia 1.0? Use Julia 0.7 for deprecation warnings!
directly below the “Download Julia 1.0” button would be a nice addition.
Well, asymptotically they have worked for a fraction of the language age that will converge to 0
I have a somewhat pragmatic approach: given that developer time is scarce, I would rather see it focused on things other than keeping an implicit history of the language in Base just to be able to guide users about an upgrade path after the deprecation period has expired. Especially since we have amazing tools to update code.
Of course, if someone wants to maintain a parallel version of Julia with nice deprecation messages going back to ancient versions, they are welcome to do so (it is conceptually trivial, just a lot of tedious work). This could of course live in a package. Ultimately all of the discussions about what the language should do in these cases boils down to someone putting in the work.