4 ms·

It was literally released today. Of course the packages don't work yet...

LittlePeter 8y ago
That makes sense. Maybe I was used to R (CRAN) where uploaded packages are actually tested against the version they declare to support.
- candhee 8y ago
  JuliaDB declares support for 0.6 not 1.0 - http://juliadb.org/latest/ http://juliadb.org/latest/ Which package declared support for 1.0.0 and didn’t compile?
  - kgwgk 8y ago
    A binary package will be available in CRAN for a given platform/version only if it works (it passes all the tests). It seems that Julia lets you install a non-working package without any warning (you will probably get errors when you run it, but I guess it may also fail silently which is worse).
    - et2o 8y ago
      I was excited to try using Julia 1.0.0 today after a couple years since my last try and... couldn’t. None of the packages work with it yet. I guess I could go find an older version, but it seems like a problem that Julia will happily allow you to install a package it isn’t compatible with. What’s the point of the Pkg system then? CRAN’s model makes a lot more sense.
      - StefanKarpinski 8y ago
        Many packages have declared them selves compatible with any future version of Julia... which is clearly a lie. These need upper bounds on their version compatibility, but that will take some time to propagate through the system.
    - kwertzzz 8y ago
      This is indeed a very good idea. In Julia, the package author defines the range of supported Julia version. Most package actually just say "version 0.6 or later". The JuliaDB package was just been updated preventing the installation on Julia 0.7 or 1.0: https://github.com/JuliaComputing/JuliaDB.jl/commit/8bf3057df154b7d0b592248bb3be98171dd28738 https://github.com/JuliaComputing/JuliaDB.jl/commit/8bf3057d... A automatic check as in R would indeed a better choice.
      - tavert 8y ago
        That will only prevent installation of master of the package or the immediate next few versions on 0.7. The old package versions without a julia upper bound remain available so users on 0.7 or 1.0 will just be held back to old versions of JuliaDB until a new release without an upper bound gets made.
- celrod 8y ago
  On each packages GitHub page, there should be unit test info, including badges that link to Travis and/or Appveyor, indicating where they were treated and whether they passed. If the tests haven't run in a while, they wouldn't have been tested on 1.0. Waiting a month may be a good bet.
- disgruntledphd2 8y ago
  That probably didn't happen at R 1.0.0. (Release notes: ftp://cran.r-project.org/pub/R/R-release-1.0.0.html). More informative wikipedia page: https://en.wikipedia.org/wiki/R_(programming_language)#CRAN https://en.wikipedia.org/wiki/R_(programming_language)#CRAN That being said, R was GNU S once upon a time, so they didn't really build a new language, rather an open source clone of a popular proprietary tool. (In case it wasn't clear I both love R and am madly excited that Julia has finally hit 1.0.0).
- currymj 8y ago
  CRAN has extremely strong requirements around testing, compatibility, documentation, all aggressively enforced by the maintainers of the repository. The Julia package ecosystem is much more anarchic, like npm. You basically just have to have a public git repository with certain files in place, and a cursory review from the managers of the package metadata. There are tradeoffs. I'm honestly not sure which one is the right way. I really appreciate how much I can trust that a CRAN package works, but there's a reason so many R devs are using devtools to do an end-run around it.
celrod 8y ago
Is there anything wrong with recommending 0.7? Most things seem to work by now.
- ChrisRackauckas 8y ago
  v0.7 is mostly for developers upgrading packages. It is nice because it throws warnings instead of errors for things that changed. So if it works on v0.7 without depwarns then it will be 1.0 compatible. But in many cases it's not perfect yet, so staying at v0.6 can be nicer than throwing a bunch of depwarns at new users.
driverdan 8y ago
I've never used Julia but why would a language make breaking changes on each release? It doesn't have backwards compatibility? That sounds like a nightmare to work with. Is it because it was pre-1.0?
- ChrisRackauckas 8y ago
  Yes. v1.0 is literally the release so that all future 1.x releases are backwards compatible. That's why it's such a big deal.
- celrod 8y ago
  Exactly, and that is why 1.0 is a big deal: the end of breaking changes until Julia 2.0.
- KenoFischer 8y ago
  Pre 1.0, we've generally provided backwards compatibility for one version with deprecations. Somewhat ironically that has often led to people just living with walls of warnings until the version that actually broke it came out, which led to a worse experience. We also have automated upgrade tools now, which can do many of the simple (and some not so simple ones) automatically. The situation on 1.0 is slightly worse than in previous releases because we released 0.7 and 1.0 simultaneously to avoid having to ship 1.0 with active deprecations. Of course that means that people will have to fix their packages now, rather than waiting until next year.

That makes sense. Maybe I was used to R (CRAN) where uploaded packages are actually tested against the version they declare to support.

candhee 8y ago
JuliaDB declares support for 0.6 not 1.0 - http://juliadb.org/latest/ http://juliadb.org/latest/ Which package declared support for 1.0.0 and didn’t compile?
- kgwgk 8y ago
  A binary package will be available in CRAN for a given platform/version only if it works (it passes all the tests). It seems that Julia lets you install a non-working package without any warning (you will probably get errors when you run it, but I guess it may also fail silently which is worse).
  - et2o 8y ago
    I was excited to try using Julia 1.0.0 today after a couple years since my last try and... couldn’t. None of the packages work with it yet. I guess I could go find an older version, but it seems like a problem that Julia will happily allow you to install a package it isn’t compatible with. What’s the point of the Pkg system then? CRAN’s model makes a lot more sense.
    - StefanKarpinski 8y ago
      Many packages have declared them selves compatible with any future version of Julia... which is clearly a lie. These need upper bounds on their version compatibility, but that will take some time to propagate through the system.
  - kwertzzz 8y ago
    This is indeed a very good idea. In Julia, the package author defines the range of supported Julia version. Most package actually just say "version 0.6 or later". The JuliaDB package was just been updated preventing the installation on Julia 0.7 or 1.0: https://github.com/JuliaComputing/JuliaDB.jl/commit/8bf3057df154b7d0b592248bb3be98171dd28738 https://github.com/JuliaComputing/JuliaDB.jl/commit/8bf3057d... A automatic check as in R would indeed a better choice.
    - tavert 8y ago
      That will only prevent installation of master of the package or the immediate next few versions on 0.7. The old package versions without a julia upper bound remain available so users on 0.7 or 1.0 will just be held back to old versions of JuliaDB until a new release without an upper bound gets made.
celrod 8y ago
On each packages GitHub page, there should be unit test info, including badges that link to Travis and/or Appveyor, indicating where they were treated and whether they passed. If the tests haven't run in a while, they wouldn't have been tested on 1.0. Waiting a month may be a good bet.
disgruntledphd2 8y ago
That probably didn't happen at R 1.0.0. (Release notes: ftp://cran.r-project.org/pub/R/R-release-1.0.0.html). More informative wikipedia page: https://en.wikipedia.org/wiki/R_(programming_language)#CRAN https://en.wikipedia.org/wiki/R_(programming_language)#CRAN That being said, R was GNU S once upon a time, so they didn't really build a new language, rather an open source clone of a popular proprietary tool. (In case it wasn't clear I both love R and am madly excited that Julia has finally hit 1.0.0).
currymj 8y ago
CRAN has extremely strong requirements around testing, compatibility, documentation, all aggressively enforced by the maintainers of the repository. The Julia package ecosystem is much more anarchic, like npm. You basically just have to have a public git repository with certain files in place, and a cursory review from the managers of the package metadata. There are tradeoffs. I'm honestly not sure which one is the right way. I really appreciate how much I can trust that a CRAN package works, but there's a reason so many R devs are using devtools to do an end-run around it.

celrod 8y ago

Is there anything wrong with recommending 0.7? Most things seem to work by now.

ChrisRackauckas 8y ago
v0.7 is mostly for developers upgrading packages. It is nice because it throws warnings instead of errors for things that changed. So if it works on v0.7 without depwarns then it will be 1.0 compatible. But in many cases it's not perfect yet, so staying at v0.6 can be nicer than throwing a bunch of depwarns at new users.

driverdan 8y ago

I've never used Julia but why would a language make breaking changes on each release? It doesn't have backwards compatibility? That sounds like a nightmare to work with. Is it because it was pre-1.0?

ChrisRackauckas 8y ago
Yes. v1.0 is literally the release so that all future 1.x releases are backwards compatible. That's why it's such a big deal.
celrod 8y ago
Exactly, and that is why 1.0 is a big deal: the end of breaking changes until Julia 2.0.
KenoFischer 8y ago
Pre 1.0, we've generally provided backwards compatibility for one version with deprecations. Somewhat ironically that has often led to people just living with walls of warnings until the version that actually broke it came out, which led to a worse experience. We also have automated upgrade tools now, which can do many of the simple (and some not so simple ones) automatically. The situation on 1.0 is slightly worse than in previous releases because we released 0.7 and 1.0 simultaneously to avoid having to ship 1.0 with active deprecations. Of course that means that people will have to fix their packages now, rather than waiting until next year.