Deprecate packages

[IainNZ]

This is my attempt to kill off some packages, a test of the idea of using a max Julia version as a safe way of doing it that should break existing installs (hopefully).

• Package isn't deleted
• Listing generators like my one won't list them
• Can override the version limit if you want to install (to e.g. recreate results)

Related discussion here: JuliaLang/julia#6669

This deprecates:

• REPLCompletions, Terminals, REPL, LineEdit Tag REPL.jl and dependent packages as merged into Julia master #732
• Monads.jl (Doesn't load on 0.2 or 0.3 ulysses4ever/Monads.jl#4)
• Trie.jl (remove Trie.jl, as it is now part of DataStructures.jl #820)
• Bebop.jl (https://github.com/zhemao/Bebop.jl/issues/1)

Should the Julia max versions be 0.3 or 0.3-?

[StefanKarpinski]

Seems reasonable to me. The upper bound is the question – this will cause these packages to be uninstallable once we actually tag 0.3 but not until then. Which seems fine. Using 0.3- as an upper bound would cause these packages to be uninstallable nowish.

[IainNZ]

Yeah, my logic was that we are in the [0.2, 0.3) period so things shouldn't disappear during the interval they are declared deprecated, but when we tag 0.3 we are in the [0.3, 0.4) interval so they should stop working (well, easily accessed) then.

[IainNZ]

@loladiro, just wanted to clarify what is being deprecated and what isn't (is it everything?)

[StefanKarpinski]

Yes, that seems reasonable to me. I'm kind of starting to regret that we used version numbers instead of commit hashes for this kind of thing. It's often the case that certain things work before a specific hash and not afterwards. I wonder if that would be easier or just too unintutive.

[kmsquire]

JuliaLang/julia#3465

On Thu, May 15, 2014 at 1:02 PM, Stefan Karpinski
notifications@github.comwrote:

Yes, that seems reasonable to me. I'm kind of starting to regret that we
used version numbers instead of commit hashes for this kind of thing. It's
often the case that certain things work before a specific hash and not
afterwards. I wonder if that would be easier or just too unintutive.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/844#issuecomment-43257837
.

[carlobaldassi]

Aren't the numbers after + in the prerelease versions progressive? E.g. I'm on

julia> VERSION
v"0.3.0-prerelease+3064"

Assuming this is the case, Pkg should work just fine if the exact version is specified.

[Keno]

Yeah, Terminals/REPL/LineEdit should be deprecated, since that's now in Base (there's some stuff missing from Base, but I'll probably make that a TerminalsExtensions.jl package or sth).

[pao]

Thank you @IainNZ for getting this for me. I haven't had the opportunity to do much more than drive-bys recently.

[staticfloat]

@StefanKarpinski Determining an ordering between git hashes would be rather expensive, I think. You'd need to query potentially huge portions of the git database every time you resolve()'ed. @carlobaldassi's idea of including the build number is a lot cheaper and likely to do what we want. Even though the build number is just the distance (in commits) from the v0.2.1 tag and HEAD, that is probably reliable enough for moderating the bleeding edge of things. Anything that's not bleeding edge shouldn't need to worry about this kind of stuff, since it's only the bleeding edge where we have incompatibilities within a minor version.

[IainNZ]

Alright, pulling trigger on this one.