DataFrames.jl currently supports Julia 1.0. We would like to drop this support and require at least Julia 1.6.
If anyone objects to this please comment in this thread. Thank you!
13 Likes
It seems DataFrames.jl has 672 dependents (DataFrames.jl at JuliaHub) which is great!. It is more important to take care if they will be affected or not.
1 Like
I have just checked it - seems that most packages that allow Julia 1.0 do it because they can, the question is if anyone uses them on Julia 1.0. Which means that we should target a wider audience that only direct DataFrames.jl users (which is hard).
3 Likes
You should do this. JuMP and SciML are both committing to supporting the LTS and later and have lower bounds of 1.6.
Note that people can still install and use DataFrames on Julia 1.0, theyll just get an older version.
15 Likes
Does DataFrames.jl currently use any v.1.6 or higher version specific future which is not supported in previous versions?
1 Like
I don’t understand the question, you can drop 1.6 support in newer version of DataFrames (and it’s not even a breaking release)
people can still use old DataFrame
No - you can code everything in Julia 1.0 if you want and this is what we always did in the past. Of course sometimes it leads to ugly code but it is doable. An example, not that ugly, but showing that we made sure in the past to ensure this support is DataFrames.jl/fastaggregates.jl at 67ccc074796fb35e8b8879b2dfa160c682442eba · JuliaData/DataFrames.jl · GitHub or DataFrames.jl/complextransforms.jl at a6820227d7794cb2cc6ee44bc86991bdb29614c5 · JuliaData/DataFrames.jl · GitHub.
The context is Use PrettyTables.jl as HTML backend by ronisbr · Pull Request #3096 · JuliaData/DataFrames.jl · GitHub. PrettyTables.jl on which DataFrames.jl depends dropped Julia 1.0 support.
4 Likes
PrettyTables.jl v2.0 has a lot of performance tuning that dropped the time to print the first table from 0.8 to 0.5s comparing to v1.3.1. However, for some reason (I think related to precompilation), it takes almost 4s in Julia 1.0. That’s why I decided to drop support for Julia 1.0 and only test against 1.6.
My concern is that it is bad for DataFrames and PrettyTables to have such a bad performance in Julia 1.0. If people wants to use, they can still use the current versions, which has acceptable performance.
6 Likes
opps, the code reads like Android Java app with to many decisions on version info…
That’s a difficult trade-off. Would people on Julia 1.0 prefer to have the latest DataFrames.jl version even if it’s slow to load, or the previous one which is relatively fast but without new features? I think I would have leaned towards the former, as that allows using code (and packages depending on recent DataFrames.jl features) on Julia 1.0 that would otherwise not work at all. Also people can easily go back to the previous version if they prefer it.
That said, I admit that it could be a bad experience for people who would like to continue running the same code on Julia 1.0 as they have used in a long time (so no need for new features), and it suddenly becomes slower. Having to go back manually to the previous version could be annoying.
If you are running julia v1.0, you can’t really expect new features right? I have no stake in this question, but to me running such an old version of Julia, much older than the current LTS, is an indication that you want absolutely nothing to change.
11 Likes
@nalimilan I think two crucial questions I want to get answer for in this thread are:
- are there any direct or indirect users of DataFrames.jl that are on Julia earlier than 1.5
- even if there are such users do they want to use latest version of DataFrames.jl or they plan to stick to old version (because they do not want to change anything and just have some code that needs to keep working)
Because the only problematic scenario for us is - users that have to use Julia 1.0 but at the same time want to upgrade DataFrames.jl to 1.4 version. The assumption is that the set of such users is empty. But with this thread I wanted to verify this.
6 Likes
Nobody has to use Julia 1.0; and with latest DataFrames. It’s just bizarre to me we want to support 1.0, with new features. [Some people might need 1.3, because of Cxx.jl.]
@Ronis_BR - does PrettyTables.jl 2.0 support 1.3 or it strictly requires at least 1.6?
Actually, the code runs in Julia 1.0. The only real problem is the performance. For some reason I cannot explain, it is very slow. I need to check the performance in Julia 1.3. However, since Julia 1.3 was not an LTS release, what is the big difference between the discussion about requiring Julia 1.0 or 1.3?
1 Like
Yes, 1.0 was an LTS, but a long time ago, so I hardly see it relevant. It’s entirely up to you if you want to allow 1.3 in Projects.toml (and test on?). I’m just saying if you want to, I think you easily could.
Julia is a very new language. The user experience between 1.0 and 1.8 just leaped to another level. I think we should encourage people to update Julia, which should not be a problem at all because it is backwards compatible.
People using legacy versions that are not even supported (< 1.6) probably does not want to update DataFrames.jl at all.
Finally, the number of features between 1.0 and 1.6 is huge. Keeping support for old versions adds pressure to the code maintainability. In Linux, for example, the EOL of LTS is the final support window. I think we should also do this in Julia. When an LTS reaches EOL, the new versions of packages should target the new LTS.
Notice that old versions will continue to work as it is due to Pkg.jl, they will just not get new features.
7 Likes
Yes, this should be easy. However, my point is that those versions are not supported anymore. Let’s suppose we, for some reason, find a bug in Julia 1.3. There will not be a v1.3.2.
1 Like
My position here is the following:
- LTS status is largely irrelevant for the discussion
- I want DataFrames.jl to be sure that they can run their code in the long run (this is critically relevant for enterprise users)
Having said that no one forces someone to use DataFrames.jl 1.4 (upcoming release) and Julia 1.0. Such users can just use DataFrames.jl 1.3 most likely. Same with Julia 1.3 users - they can use DataFrames.jl 1.3 without a problem. This is exactly related to Cxx.jl discussion - some users are likely to ask why Julia 1.3 should be more special than Julia 1.0 (except for some specific package).
However, in this tread I want to verify if this reasoning is not broken for someone. Again:
If we start requiring Julia 1.6 in DataFrames.jl 1.4 release is anyone going co complain?
(sorry for being so direct, but I would prefer the discussion to be focused on this question solely as otherwise it will very quickly branch off to various subtopic).
If someone wants to know why Julia 1.3 is problematic for DataFrames.jl see e.g.: DataFrames.jl/utils.jl at a6820227d7794cb2cc6ee44bc86991bdb29614c5 · JuliaData/DataFrames.jl · GitHub
6 Likes
I do not complain with targeting 1.6, if that’s easier. We should at least support (that) current LTS, and e.g. SciML has chosen it as a lowest supported. As you say Julia 1.3 will still work, with older DF. I’m not suggesting maintenance burden for 1.3, only if it comes for free (I was just thinking of any reason to support older than 1.6, and can only justify 1.3); it can also be dropped later, or alternatively now, and later extended further back if needed. I don’t know how large the intersection of Cxx and DF (and possibly SciML) usage is:
Please, note that Cxx.jl only works (out of the box) currently with Julia 1.1.x to 1.3.x, i.e. with no currently supported Julia, while those versions can still be downloaded at Julialang.org.
1 Like