4 ms·

The rapid release cycle is going to pose challenges downstream for all the people developing tooling and other aspects of the ecosystem which are not used to mo

by zmmmmm 9y ago

The rapid release cycle is going to pose challenges downstream for all the people developing tooling and other aspects of the ecosystem which are not used to moving that fast (eg: Groovy still grappling with the module changes to Java9, let alone 10 or 11). While we all griped about it for many years, the slow pace of Java evolution was in some ways one of it's biggest features. I am curious to see whether the community starts to move fast too, or if actually what happens is that people completely ignore the non-LTS versions and we actually get an effective release cadence of 2-3 years or so in practice.

giancarlostoro 9y ago
That's just it, some projects will likely try to catch up just in time for the next LTS, while others may run a similar set of release branches, one targeting the LTS or the latest release. It's really dependent on individual projects, not so much the whole ecosystem at once. In Rust we have web frameworks that run on the Stable compiler, and then there's Rocket which currently only runs on the nightly compiler (at least last I checked).
- steveklabnik 9y ago
  Rocket is still on nightly, though getting pretty close!
jldugger 9y ago
Hopefully the faster release cycle is tied with smaller changesets per release.
kjeetgill 9y ago
I think the jump to 9 is going to be a little rough while organisations figure out modules and all the new flags tickle into a billion build scripts but 10 and 11 don't seem too bad. I heard one good approach is to start testing newer releases in your CI systems as soon as possible but wait for the next LTS ever few years to migrate production.
vorg 9y ago
> Groovy still grappling with the module changes to Java9, let alone 10 or 11 Apache Groovy hasn't even updated its syntax to support Java 8 lambdas. It's coming in Groovy 3, apparently.
- oweiler 9y ago
  Which is hardly a problem because of Closure Coercion.
  - vorg 9y ago
    If not having lambdas in Groovy isn't a problem, then why are they coming in Groovy 3 ?
    - zmmmmm 9y ago
      Groovy 3 is full of nice-to-haves. Which is why it's taken forever. Anything that was a "problem" as you say got put into 2.4 / 2.5 (except for solving the Java9 module problem which is unsolved in any release ...).
      - vorg 9y ago
        It sounds like Groovy 3 is just a forever-pending product designed to be a catchment for the stuff Groovy's backers aren't really very concerned about, or perhaps don't even want put into Groovy. It's still in alpha, being delayed until after a Groovy 2.6 release and the project managers have had a "conversation" sometime down the line about what features should go into Groovy 3. If Groovy's project managers at Apache don't want a Groovy 3 release to avoid a debacle like Python 3 or Grails 3, then they should just come out and say so. Instead, they're letting others waste their time working on it while putting up roadblock after roadblock to slow it down.
    - olavgg 9y ago
      Personally, I just write lambda or try with resources in Java. Groovy is great, but not for everything, I still write Javaish and with static typing whenever I write Groovy. Calling Java code from Groovy and Groovy from Java again is easy as they share the byte code.
repolfx 9y ago
If you can make it past 8 to 9 then 9 to 10 and 10 to 11 are much easier. The reason the community is struggling with Java 8 to Java 9 is that 9 broke a TON of stuff. It's not backwards compatible at all. Basically every non-trivial app broke. The breakages are mostly in things that were technically never guaranteed, even trivial things like the version number went from "1.8" to "9" which makes sense but broke loads of programs that tried to parse the version. But some of it is also just bad processes and habits in the community. Some of the programs that broke due to the version number change from 8 to 9 broke again from 9 to 10 just months later because they had enums that listed every possible version.... their codebase literally encoded the assumption that new major java releases hardly ever happened!

by zmmmmm 9y ago

giancarlostoro 9y ago

That's just it, some projects will likely try to catch up just in time for the next LTS, while others may run a similar set of release branches, one targeting the LTS or the latest release. It's really dependent on individual projects, not so much the whole ecosystem at once. In Rust we have web frameworks that run on the Stable compiler, and then there's Rocket which currently only runs on the nightly compiler (at least last I checked).

steveklabnik 9y ago
Rocket is still on nightly, though getting pretty close!

jldugger 9y ago

Hopefully the faster release cycle is tied with smaller changesets per release.

kjeetgill 9y ago

I think the jump to 9 is going to be a little rough while organisations figure out modules and all the new flags tickle into a billion build scripts but 10 and 11 don't seem too bad. I heard one good approach is to start testing newer releases in your CI systems as soon as possible but wait for the next LTS ever few years to migrate production.

vorg 9y ago

> Groovy still grappling with the module changes to Java9, let alone 10 or 11 Apache Groovy hasn't even updated its syntax to support Java 8 lambdas. It's coming in Groovy 3, apparently.

oweiler 9y ago
Which is hardly a problem because of Closure Coercion.
- vorg 9y ago
  If not having lambdas in Groovy isn't a problem, then why are they coming in Groovy 3 ?
  - zmmmmm 9y ago
    Groovy 3 is full of nice-to-haves. Which is why it's taken forever. Anything that was a "problem" as you say got put into 2.4 / 2.5 (except for solving the Java9 module problem which is unsolved in any release ...).
    - vorg 9y ago
      It sounds like Groovy 3 is just a forever-pending product designed to be a catchment for the stuff Groovy's backers aren't really very concerned about, or perhaps don't even want put into Groovy. It's still in alpha, being delayed until after a Groovy 2.6 release and the project managers have had a "conversation" sometime down the line about what features should go into Groovy 3. If Groovy's project managers at Apache don't want a Groovy 3 release to avoid a debacle like Python 3 or Grails 3, then they should just come out and say so. Instead, they're letting others waste their time working on it while putting up roadblock after roadblock to slow it down.
  - olavgg 9y ago
    Personally, I just write lambda or try with resources in Java. Groovy is great, but not for everything, I still write Javaish and with static typing whenever I write Groovy. Calling Java code from Groovy and Groovy from Java again is easy as they share the byte code.

repolfx 9y ago

If you can make it past 8 to 9 then 9 to 10 and 10 to 11 are much easier. The reason the community is struggling with Java 8 to Java 9 is that 9 broke a TON of stuff. It's not backwards compatible at all. Basically every non-trivial app broke. The breakages are mostly in things that were technically never guaranteed, even trivial things like the version number went from "1.8" to "9" which makes sense but broke loads of programs that tried to parse the version. But some of it is also just bad processes and habits in the community. Some of the programs that broke due to the version number change from 8 to 9 broke again from 9 to 10 just months later because they had enums that listed every possible version.... their codebase literally encoded the assumption that new major java releases hardly ever happened!