Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Drop support for Julia < 0.7 #652

Closed
wants to merge 1 commit into from
Closed

Drop support for Julia < 0.7 #652

wants to merge 1 commit into from

Conversation

ararslan
Copy link
Member

@ararslan ararslan commented Feb 9, 2019

The time has come, as 0.6 is unmaintained.

Fixes #651.

@ararslan
Drop support for Julia < 0.7
0d1a94f 
The time has come, as 0.6 is unmaintained.

Fixes #651.
@martinholters
Copy link
Member

martinholters commented Feb 9, 2019 •
edited
Loading

On the phone right now, so cannot review properly, but looks like you are already removing the deprecations from #646 here which haven't been active on any release, yet. That would mean we tag 2.0 now and then 3.0 after this one lands (eventually). Is that your plan? Alternatively, we could keep the deprecations and tag 2.0 after merging this one.

@ararslan
Copy link
Member Author

ararslan commented Feb 9, 2019

Yeah I figured we'd do another release with deprecations before this lands.

@martinholters
Copy link
Member

Tag v2.0.0 now, and leave this open for a while (weeks to months)? Or do a v3.0.0 with this soon after (similar to julia 0.7/1.0)? I wouldn't like the latter; I don't think anyone would consciously upgrade to 2.0 first, fix deprecations, then update to 3.0.

The former would be ok with me, although I think I'd prefer to to do the dropping of 0.6 now for 2.0. Then packages (or package versions) which don't support julia later than 0.6 don't have to worry about capping their required Compat version.

martinholters
martinholters reviewed Feb 11, 2019
View reviewed changes
src/Compat.jl
# Bindings that were available at the top level in Compat
using Base: notnothing
using Dates: AbstractDateTime
using LinearAlgebra: dot, norm, opnorm, qr, rmul!, tr
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we keep these? I guess we could safely deprecate them.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On second thought, we can deprecate these in another PR (if we want to), and can keep this PR strictly to dropping pre-0.7 support.

@martinholters
Copy link
Member

I wonder what we should do with all the imported stdlibs. There is not much reason to keep them at this point (i.e. we could deprecated Compat.XYZ to XYZ). However, if we backport additions to stdlibs, we would need to re-introduce (and extend) them. Should we therefore just keep them?

martinholters
martinholters requested changes Feb 11, 2019
View reviewed changes
Copy link
Member

@martinholters martinholters left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some else branches seem to be gone for good which we should keep, probably deprecated. Compat use is so wide-spread I'd really prefer it to behave well even across major version bumps.

src/Compat.jl
Base.invokelatest(inner)
end
else
import Base.invokelatest
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should add a deprecation for this binding.

src/Compat.jl
if VERSION < v"0.7.0-DEV.3216"
const AbstractDateTime = Compat.Dates.TimeType
else
const AbstractDateTime = Compat.Dates.AbstractDateTime
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Deprecation.

src/Compat.jl
const IteratorEltype = Base.iteratoreltype
else
const IteratorSize = Base.IteratorSize
const IteratorEltype = Base.IteratorEltype
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Deprecations for these two.

@ararslan
Copy link
Member Author

However, if we backport additions to stdlibs, we would need to re-introduce (and extend) them

Yeah, that is an issue and I'm not sure how best to go about that aside from what we currently do, which is define Compat.X for each X as an actual submodule of Compat, which kind of sucks...

@musm
Copy link
Contributor

musm commented Mar 20, 2019

👍 Didn't you plan to also drop 0.7 since it is unmaintained?

@ararslan
Copy link
Member Author

Oh, good call. I should do that as well, thanks @musm.

@nickrobinson251
Copy link
Contributor

Bump? 🙏

@ararslan
Copy link
Member Author

I don't know when I'll have time to revisit this, so I encourage anyone who's interested to take the reins and use this branch for reference.

@mcabbott mcabbott mentioned this pull request Sep 29, 2019
Merged
mcabbott
mcabbott reviewed Sep 29, 2019
View reviewed changes
README.md
not yet part of the standard library ([#27834]).
`Compat.X` is available for every stdlib package `X` for backwards compatibility with
previous verisons of Compat.
Newer code should use `X` directly.

## New functions, macros, and methods

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might be helpful to state the order here, and organise by what version of Julia supports the feature:

Suggested change
Latest addions are at the top of each list:
### New in Julia 1.4
### New in Julia 1.3
### New in Julia 1.2
### New in Julia 1.1

@martinholters martinholters mentioned this pull request Oct 9, 2019
Merged
@martinholters
Copy link
Member

Superseded by #665.

@martinholters martinholters deleted the aa/the-future branch October 13, 2019 07:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@martinholters martinholters martinholters requested changes

@mcabbott mcabbott mcabbott left review comments

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

Compat: Forging ahead in the 1.x era
5 participants
@ararslan @martinholters @musm @nickrobinson251 @mcabbott