Add 3.4.0 blogpost

_data/scala-releases.yml

@@ -1,7 +1,11 @@
+- category: current_version
+  title: Current 3.4.x release
+  version: 3.4.0
+  release_date: February 29, 2024
 - category: current_version
   title: Current 3.3.x LTS release
-  version: 3.3.1
-  release_date: September 9, 2023
+  version: 3.3.3
+  release_date: February 29, 2024
 - category: current_version
   title: Current 2.13.x release
   version: 2.13.12

_downloads/2024-02-29-3.3.3.md

@@ -0,0 +1,10 @@
+---
+title: Scala 3.3.3 LTS
+start: 29 February 2024
+layout: downloadpage
+release_version: 3.3.3
+release_date: "February 29, 2024"
+permalink: /download/3.3.3.html
+license: <a href="https://www.scala-lang.org/license/">Apache License, Version 2.0</a>
+api_docs: https://www.scala-lang.org/api/3.3.3/
+---

_downloads/2024-02-29-3.4.0.md

@@ -0,0 +1,10 @@
+---
+title: Scala 3.4.0
+start: 29 February 2024
+layout: downloadpage
+release_version: 3.4.0
+release_date: "February 29, 2024"
+permalink: /download/3.4.0.html
+license: <a href="https://www.scala-lang.org/license/">Apache License, Version 2.0</a>
+api_docs: https://www.scala-lang.org/api/3.4.0/
+---

blog/_posts/2024-02-29-scala-3.4.0-and-3.3.3-released.md

@@ -0,0 +1,241 @@
+---
+layout: blog-detail
+post-type: blog
+by: Paweł Marks, VirtusLab
+title: Scala 3.4.0 and 3.3.3 LTS released!
+---
+
+![Scala 3.4]({{ site.baseurl }}/resources/img/scala-3.4-launch.jpg)
+
+We are thrilled to announce the release of two versions of Scala 3: the first version in the 3.4 minor line, and a patch version in the Long Term Support line.
+
+## ... so which version should I update to?
+
+Scala 3.4.0 code can use dependencies compiled with Scala 3.3.x, but not the other way around. That means that if you are a library author, you should stay on the LTS line. Moreover, you can safely bump the patch version of the LTS release and benefit from the bugfixes without forcing any updates on the consumers of your library, even in regard to the patch version.
+
+If you are working on a project that is not meant to be used as an external dependency, feel free to update to Scala 3.4.0, especially if you are starting a new project.
+
+Scala 3.4.0 and 3.3.3 share most of the changes since the 3.3.1 version. The difference is that Scala 3.4.0 adds new features and deprecates legacy mechanisms, while version 3.3.2 is focused solely on bug fixes and usability improvements. What's more, 3.3.2, as a part of the LTS line, maintains not only full binary compatibility but also full source compatibility. **We checked that every single one of over a thousand projects that worked with 3.3.1 still work with 3.3.2.** To achieve this, we had to be extra careful with selecting changes for that release. Thus, not every bug that is fixed in 3.4.0 is also fixed in 3.3.2. Some of the not-ported changes might still land in 3.3.4.
+
+## ...wait, what happened to 3.3.2?
+
+Unfortunately, [a subtle bug](https://github.com/playframework/playframework/issues/12418) in the TASTy reader managed to survive the Release Candidate (RC) process. The bug caused 3.3.2 to emit TASTy files incompatible with previous releases in the LTS line, namely 3.3.1 and 3.3.0. This means that, should a library author release a new version using 3.3.2, all users still based on older 3.3.x releases will encounter issues. While a simple workaround exists - users can bump their patch version in the LTS line, which is safe and recommended - we regard compatibility in the LTS as paramount. Therefore, we have decided to abandon the 3.3.2 release completely. New testing measures will be introduced to avoid such situations in the future and to guarantee that LTS line remains internally consistent in all cases.
+
+## What's new in 3.3.3 LTS (and 3.4.0 too)
+
+In the release notes of Scala [3.3.3 LTS](https://github.com/lampepfl/dotty/releases/tag/3.3.3), you can see a lot of bug fixes. One area that received special attention in that regard was coverage support. With most pains fixed, we are now confident in the state of coverage.
+
+Another important change, not directly visible to end users, is the integration of the presentation compiler into the compiler itself. This makes building tooling easier and allows for a more stable and reliable user experience when using Metals.
+
+## Changes exclusive to 3.4.0
+
+Release notes of [3.4.0](https://github.com/lampepfl/dotty/releases/tag/3.4.0) contains many substantial changes and improvements. The most noteworthy can be grouped in a few broad categories:
+
+### Stabilized SIPs
+
+- [SIP-54](https://docs.scala-lang.org/sips/multi-source-extension-overloads.html) is now a standard feature. It allows for importing extension methods with the same name from different sources.
+- [SIP-53](https://docs.scala-lang.org/sips/quote-pattern-type-variable-syntax.html) is now a standard feature. It allows for more expressive type patterns in quotes. For example:
+
+  ```scala
+  case '[ (t, t, t) ] => ???
+  ```
+
+  will match any 3-element tuple, and `t` will be the greatest lower bound of types of all three elements.
+- Match types are now properly specified, and thanks to that, they work in a more predictable and stable way. See [SIP-56](https://docs.scala-lang.org/sips/match-types-spec.html)
+
+### Improvements to the type system and inference
+
+- Type inference for functions similar to fold is greatly improved. For example:
+
+  ```scala
+  def partition[T](xs: List[T], pred: T => Boolean) =
+     xs.foldRight((Nil, Nil)): (x, p) =>
+       if pred(x) then (x :: p._1, p._2) else (p._1, x :: p._2)
+
+  ```
+
+  will have its return type correctly inferred as `(List[T], List[T])`. Earlier, it would result in a rather unintuitive type error.
+
+- It is now possible to write a polymorphic lambda without writing down the types of its value parameters as long as they can be inferred from the context, for example:
+
+  ```scala
+  val f: [T] => T => String = [T] => (x: T) => x.toString
+  ```
+
+  can now be written more concisely as:
+
+  ```scala
+  val f: [T] => T => String = [T] => x => x.toString
+  ```
+
+- The compiler now avoids generating given definitions that loop, removing a long-standing footgun in implicit resolution.
+
+### Backend improvements
+
+- Polymorphic lambdas are now implemented using JVM lambdas when possible instead of anonymous classes, which will make them more efficient.
+- JVM Backend parallelization has been ported from Scala 2 to Scala 3. Read more in the discussion under [the original PR](https://github.com/scala/scala/pull/6124).
+
+### Reporting
+
+- Scala 3.4 improves the error message when a signature from the classpath comes from an incompatible TASTy version. It has improved readability and provides a more useful diagnostic of what a user can do to fix the problem.
+
+  ```
+  error while loading Tuple,
+    TASTy file /scala/Tuple.tasty could not be read, failing with:
+    Forward incompatible TASTy file has version 28.4, produced by Scala 3.4.0,
+    expected stable TASTy from 28.0 to 28.3.
+    To read this TASTy file, use a Scala 3.4.0 compiler or newer.
+    Please refer to the documentation for information on TASTy versioning:
+    https://docs.scala-lang.org/scala3/reference/language-versions/binary-compatibility.html
+  ```
+
+- If there is an error reading a class file, we now report the version of the classfile and a recommendation to check JDK compatibility:
+
+  ```
+  error while loading String,
+    class file /modules/java.base/java/lang/String.class is broken (version 65.0),
+    please check the JDK compatibility of your Scala version (3.4.0),
+    reading aborted with class java.lang.RuntimeException:
+    foo bar
+  ```
+
+  This will improve the user experience when the class file format changes unexpectedly. This feature will be backported to Scala 3.3.3.
+- Progress reporting of compilation is now visible in IDEs. Metals IDE users will notice that compilation progress is no longer frozen at 0% when using sbt or bloop as the BSP server. IntelliJ will also correctly report progress for BSP and sbt based projects.
+- Diagnostics (including unused warnings) are now exported to SemanticDB. That will allow better handling of warnings in tooling. See [#17835](https://github.com/lampepfl/dotty/pull/17835).
+
+### Experimental changes
+
+- An experimental `@publicInBinary` annotation can mark definitions that should be treated as a part of binary API. It is useful where some protected or private-in-package definitions are used in the inlined code. When they are marked, it is harder to accidentally break the binary compatibility by doing seemingly harmless refactoring. If the accompanying `-WunstableInlineAccessors` linting option is enabled. There will be a warning about using things not marked as binary API in inlined code. Originaly it was presented in [SIP-52](https://docs.scala-lang.org/sips/binary-api.html).
+- `-experimental` compiler flags will mark all top-level definitions as `@experimental`. This means that the experimental language features and definitions can be used in the project. Note that this does not change the strong guarantees of the stability of the non-experimental code. The experimental features can only be used in an experimental scope (transitively). In 3.5, we plan to allow using this flag also in the stable releases of the compiler.
+
+### Legacy syntax depreacation
+
+Following syntax is now deprecated and will report warnings when used:
+
+- `_` type wildcards (rewrite to `?`)
+- `private[this]` (rewrite to `private`)
+- `var x = _` (rewrite to `var x = scala.compiletime.uninitialized`)
+- `with` as a type operator (rewrite to `&`)
+- `xs: _*` varargs (rewrite to `xs*`)
+- trailing `_` to force eta expansion (can be just omitted)
+
+All those rewrites will be performed automatically by the compiler if you run it with `-rewrite -source 3.4-migration` flags. If you cannot make those rewrites in your codebase, you can suppress the warnings in single file by adding
+
+```scala
+import scala.language.`3.3`
+```
+
+or globally using the `-source 3.3` flag.
+
+### Other source compatibility concerns
+
+- Refutable patterns (i.e., patterns that might not match) in a for-comprehension generator must now be preceded by `case`, or an error is reported.
+
+  e.g.
+
+  ```scala
+  val xss = List(List(1, 2), List(3))
+
+  for y :: ys <- xss do println(y > 1)
+  //  ^^^^^^^
+  // error: pattern's type ::[Int] is more specialized than the right hand
+  // side expression's type List[Int]
+  //
+  // If the narrowing is intentional, this can be communicated by adding
+  // the `case` keyword before the full pattern, which will result in a filtering
+  // for expression (using `withFilter`).
+  ```
+
+  `.withFilter` is also no longer inserted for a pattern in a generator unless prefixed by `case`, meaning improved ergonomics for many types that do not implement `.withFilter`
+- Type inference has changed for `inline` methods in 3.4, which can cause a source incompatibility at the call site. The previous behaviour can be recovered in an affected file with
+
+  ```scala
+  import scala.language.`3.3`
+  ```
+
+  alternatively, the definition can be changed to `transparent inline`, but as this is a TASTy breaking change, it is not a default recommendation. (Also, `inline` should be preferred when possible over `transparent inline` for reduced binary size.)
+
+## Contributors
+
+Thank you to all the contributors who made the release of 3.4.0 and 3.3.3 LTS possible!
+
+According to `git shortlog -sn --no-merges 3.3.1..3.4.0` these are:
+
+```
+   474  Martin Odersky
+   296  Nicolas Stucki
+   132  Fengyun Liu
+   119  Dale Wijnand
+    77  Jamie Thompson
+    69  Sébastien Doeraene
+    60  Paweł Marks
+    32  Chris Kipp
+    27  Guillaume Martres
+    26  Rikito Taniguchi
+    21  Yichen Xu
+    19  EnzeXing
+    14  Szymon Rodziewicz
+    13  Lucas Leblanc
+    12  Jakub Ciesluk
+    12  Jędrzej Rochala
+    12  Katarzyna Marek
+    11  Carl
+    10  David Hua
+     9  Florian3k
+     9  Wojciech Mazur
+     8  Eugene Flesselle
+     8  ghostbuster91
+     7  Hamza Remmal
+     7  Jan Chyb
+     7  Ondrej Lhotak
+     7  Quentin Bernet
+     6  Julien Richard-Foy
+     6  Kacper Korban
+     6  Seth Tisue
+     5  Lorenzo Gabriele
+     5  Matt Bovel
+     5  Som Snytt
+     5  Yuito Murase
+     5  dependabot[bot]
+     3  David
+     3  Lucas
+     3  Pascal Weisenburger
+     3  Tomasz Godzik
+     2  Aleksander Rainko
+     2  Decel
+     2  Guillaume Raffin
+     2  Ondřej Lhoták
+     2  Oron Port
+     2  danecek
+     2  rochala
+     1  Adam Dąbrowski
+     1  Aleksey Troitskiy
+     1  Arnout Engelen
+     1  Ausmarton Zarino Fernandes
+     1  Bjorn Regnell
+     1  Daniel Esik
+     1  Eugene Yokota
+     1  Fabián Heredia Montiel
+     1  François Monniot
+     1  Jakub Cieśluk
+     1  John Duffell
+     1  John M. Higgins
+     1  Justin Reardon
+     1  Kai
+     1  Kisaragi
+     1  Lucas Nouguier
+     1  Lukas Rytz
+     1  LydiaSkuse
+     1  Martin Kucera
+     1  Martin Kučera
+     1  Matthew Rooney
+     1  Matthias Kurz
+     1  Mikołaj Fornal
+     1  Nicolas Almerge
+     1  Preveen P
+     1  Shardul Chiplunkar
+     1  Stefan Wachter
+     1  philippus
+     1  q-ata
+     1  slim
+```