More polish on 3.4 announcement

blog/_posts/2024-02-26-scala-3.4.0-and-3.3.2-released.md

@@ -8,7 +8,9 @@ We are thrilled to announce the release of two versions of Scala 3: the first ve
 
 ## ... 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 consider staying on the LTS line. 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 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.2 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.3.
 
@@ -36,28 +38,29 @@ Release notes of [3.4.0](https://github.com/lampepfl/dotty/releases/tag/3.4.0) c
 
 ### Improvements to the type system and inference
 
-- 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:
+- Type inference for functions similar to fold is greatly improved. For example:
 
   ```scala
-  val f: [T] => T => String = [T] => (x: T) => x.toString
+  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)
+
   ```
 
-  can now be written more concisely as:
+  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 => x.toString
+  val f: [T] => T => String = [T] => (x: T) => x.toString
   ```
 
-- Type inference for functions similar to fold is greatly improved. For example:
+  can now be written more concisely as:
 
   ```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)
-
+  val f: [T] => T => String = [T] => x => x.toString
   ```
 
-  will have its return type correctly inferred as `(List[T], List[T])`. Earlier, it would result in a rather unintuitive type error.
 - The compiler now avoids generating given definitions that loop, removing a long-standing footgun in implicit resolution.
 
 ### Backend improvements
@@ -68,6 +71,7 @@ Release notes of [3.4.0](https://github.com/lampepfl/dotty/releases/tag/3.4.0) c
 ### 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:
@@ -107,7 +111,13 @@ Following syntax is now deprecated and will report warnings when used:
 - `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.
+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