v1.2.4

bloop v1.2.4 🏄

Upgrade guide 🔌

This section describes the upgrade steps. If you don't have bloop installed, please read
the installation instructions instead.

If you're on macOS, upgrade to the latest version with:

$ brew upgrade scalacenter/bloop/bloop
$ brew services restart bloop

If you're on Windows using scoop, upgrade to the latest version with:

$ scoop upgrade bloop
$ bloop ng-stop
$ // Start the server as you usually do (via systemd, manually, desktop services)

Otherwise, run:

$ curl -L https://github.com/scalacenter/bloop/releases/download/v1.2.4/install.py | python
$ bloop ng-stop
$ // Start the server as you usually do (via systemd, manually, desktop services)

Read the complete installation instructions in our Installation page.

Highlights 📚

v1.2.4 is only a bugfix release.

Don't deduplicate diagnostics too aggressively

Fix an error where the deduplication logic of diagnostics to avoid duplicated scalac errors
relied on pointer instead of offset.

Contributors 👥

According to git shortlog -sn --no-merges v1.2.3..v1.2.4, 1 people contributed to this v1.2.4
release: Jorge Vicente Cantero.

v1.2.3

bloop v1.2.3 🏄

Upgrade guide 🔌

This section describes the upgrade steps. If you don't have bloop installed, please read
the installation instructions instead.

If you're on macOS, upgrade to the latest version with:

$ brew upgrade scalacenter/bloop/bloop
$ brew services restart bloop

If you're on Windows using scoop, upgrade to the latest version with:

$ scoop upgrade bloop
$ bloop ng-stop
$ // Start the server as you usually do (via systemd, manually, desktop services)

Otherwise, run:

$ curl -L https://github.com/scalacenter/bloop/releases/download/v1.2.3/install.py | python
$ bloop ng-stop
$ // Start the server as you usually do (via systemd, manually, desktop services)

Read the complete installation instructions in our Installation page.

Highlights 📚

v1.2.3 is only a bugfix release.

Don't fail installation when Python 3 is used and http_proxy is defined

See scalacenter/homebrew-bloop#4 for more details.

Disable failed process logs in launcher (#798)

This change clears up the logs of the launcher when processes are run and
they fail. See the linked pull request for more details.

Contributors 👥

According to git shortlog -sn --no-merges v1.2.2..v1.2.2, 2 people contributed to this v1.2.2
release: Jorge Vicente Cantero, marek1840.

v1.2.2

bloop v1.2.2 🏄

Upgrade guide 🔌

This section describes the upgrade steps. If you don't have bloop installed, please read
the installation instructions instead.

If you're on macOS, upgrade to the latest version with:

$ brew upgrade scalacenter/bloop/bloop
$ brew services restart bloop

If you're on Windows using scoop, upgrade to the latest version with:

$ scoop upgrade bloop
$ bloop ng-stop
$ // Start the server as you usually do (via systemd, manually, desktop services)

Otherwise, run:

$ curl -L https://github.com/scalacenter/bloop/releases/download/v1.2.2/install.py | python
$ bloop ng-stop
$ // Start the server as you usually do (via systemd, manually, desktop services)

Read the complete installation instructions in our Installation page.

Highlights 📚

v1.2.2 is a bugfix release.

Cache compiler plugins by default via a whitelist (#794)

Compiler plugins were found to have an important performance overhead in this scala/scala ticket.
As a result, a flag was added to cache the classloaders that loaded the compiler plugins on
every compilation run.

As that compilation flag is not well-known and most users don't even know they are using
macros/compiler plugins in their projects, it's been largely unused. This pull request tries to
change the current situation by enabling the flag for compiler plugins that have been checked to
be stateless. With this guarantee, we can enable the flag by default and provide out-of-the-box
the best compilation performance we know we can provide without any user intervention.

The compiler plugins added to the whitelist are: scala-js/scala-js, scala-native/scala-native,
wartremover/wartremover, scalameta/semanticdb, scalamacros/paradise, ghik/silencer,
sksamuel/scapegoat, scoverage/scalac-scoverage-plugin, lihaoyi/acyclic, non/kind-projector,
scalacenter/classpath-shrinker, scalacenter/scalac-profiling, softwaremill/scala-clippy,
oleg-py/better-monadic-for, tek/splain, scalaz/scalaz-deriving. They represent a big chunk of all
the compiler plugins used in the Scala community.

Bloop will not enable compiler plugin caching for Dotty and Scala 2.10, 2.11, 2.12.0, 2.12.1,
2.12.2, 2.12.3 and 2.12.4 versions. From 2.12.5 on, the flag is available in the compiler sources
and used.

Fore more information about the caching, check the pull request.

Improve diagnostics in the presence of -Yrangepos (#793)

Bloop v1.2.2 has now support for:

1. Pretty printing range positions in cli diagnostics of projects using -Yrangepos.
2. Report range positions in diagnostics for projects using -Yrangepos.
3. Deduplicates compiler diagnostics based on pointer position and severity.

Further improve BSP diagnostic reporting (#792)

Bloop v1.2.2 has improved diagnostics via BSP in the presence of no-op incremental compilations
and has changed the way progress notifications and task start/finish notifications are sent.

From this version on, progress notifications will be sent every 5% increments to avoid
overflooding the client with messages and defaulting on less but more user-friendly progress
notifications, that require almost no handling by the build client.

Likewise, task start and task finish notifications are sent now for every incremental compiler
run instead of for the whole batch compilation of a project. This will help users notice when a
given change requires several incremental compiler runs. The visibility of this implementation
detail is important to increase the sensibility for incremental compiler inefficiencies that can
be located and then fixed upstream.

Add resources to classpath by default (#796)

Thanks to @kubukoz, we have found that there
are several macro libraries that require resource directories of all the transitive dependencies
of a project to be present in the compilation classpath. One of these macro libraries was
scalaz-deriving.

To support this use case, bloop v1.2.2 adds these resource directories to the compilation
classpath by default.

Use bloop server via launchd in macOS (#786)

The launcher executed by brew services was not using bloop server but blp-server directly.
This was an oversight that is now fixed in v1.2.2, together with some more changes to ensure that
bloop server picks up correctly jvm options specified in $BLOOP_INSTALLATION_DIR/.jvmopts. In
macOS systems, the bloop installation directory is the cellar installation directory for bloop,
usually symlinked from /usr/local/bin/bloop.

bloop server will not fail if a server is already running

Unlike previous releases, bloop server now exits successfully if a server is already running.
Given the increasing use of the launcher in build integrations, this change aims to avoid
confusing errors that users could get when managing the lifecycle of the server manually via
their custom service management software (brew services, systemd, desktop entries, etc).

Fix handling of unicode characters in nailgun environment variables (scalacenter/nailgun#9)

Thanks to @marek1840, the python client should not fail if a
unicode character is present in an environment variable of your terminal.

Contributors 👥

According to git shortlog -sn --no-merges v1.2.1..v1.2.2, 2 people contributed to this v1.2.2
release: Jorge Vicente Cantero, marek1840.

v1.2.1

bloop v1.2.1 🏄

Upgrade guide 🔌

This section describes the upgrade steps. If you don't have bloop installed, please read
the installation instructions instead.

If you're on macOS, upgrade to the latest version with:

$ brew upgrade scalacenter/bloop/bloop
$ brew services restart bloop

If you're on Windows using scoop, upgrade to the latest version with:

$ scoop upgrade bloop
$ bloop ng-stop
$ // Start the server as you usually do (via systemd, manually, desktop services)

Otherwise, run:

$ curl -L https://github.com/scalacenter/bloop/releases/download/v1.2.1/install.py | python
$ bloop ng-stop
$ // Start the server as you usually do (via systemd, manually, desktop services)

Read the complete installation instructions in our Installation page.

Highlights 📚

v1.2.1 is mostly a bugfix release.

Clear bsp diagnostics earlier (#782)

Bloop's build server now clears diagnostics incrementally at the end of every incremental compiler cycle.

Document shell completion setup and use in macOS (#781)

If shell completions don't work for your macOS system, follow the Homebrew installation instructions
and jump to the completions section that links to the Homebrew guide to set up Homebrew-installed
completions.

Fixes 🐛 🔨

1. Use of transactional class file manager by default
2. Make the launcher work for v1.2.0 and not only v1.1.2

Contributors 👥

According to git shortlog -sn --no-merges v1.2.0..v1.2.1, 1 people contributed to this v1.2.1
release: Jorge Vicente Cantero.

v1.2.0

bloop v1.2.0 🏄

Upgrade guide 🔌

This section describes the upgrade steps. If you don't have bloop installed, please read
the installation instructions instead.

If you're on Mac OS X, upgrade to the latest version with:

$ brew upgrade scalacenter/bloop/bloop
$ brew services restart bloop

If you're on Windows using scoop, upgrade to the latest version with:

$ scoop upgrade bloop
$ bloop ng-stop
$ // Start the server as you usually do (via systemd, manually, desktop services)

Otherwise, run:

$ curl -L https://github.com/scalacenter/bloop/releases/download/v1.2.0/install.py | python
$ bloop ng-stop
$ // Start the server as you usually do (via systemd, manually, desktop services)

Read the complete installation instructions in our Installation page.

Highlights 📚

New bloop launcher

Bloop v1.2.0 features a launcher (:rocket:), which is a core component responsible for:

1. Managing the bloop installation and server execution.
2. Establishing a bsp connection when a server is running.

The bloop launcher is a response to the reticency of depending on bloop because it needs to be
installed globally. Developer tools that want to use bloop either via BSP or CLI can depend on and
run the launcher (a ~112KB jvm artifact) to install and get a working build server in the background
out-of-the-box, getting an automatic setup in their users' machines.

The Launcher Reference page documents
the inner workings of the launcher and explains how to interact with it.

Compile, test and run several projects in one command (#772)

The compile, test and run actions now take several projects as arguments to run an action for
several projects in one go. For example, compile foo, bar and baz with:

→ bloop compile foo bar baz
Compiling foo (1 Scala source)
Compiled foo (290ms)
Compiling bar (1 Scala source)
Compiled bar (455ms)
Compiling baz (1 Scala source)
Compiled baz (229ms)

This feature comes in handy when you have several independent subgraphs inside the same build. The
Quickstart page documents the above behaviour.

Support --cascade in compile and test (#773)

The --cascade flag in a compile invocation allows you to change the public signature of a project
(say, foo) and have bloop compile all the transitive projects depending on foo to detect
compilation errors. When added to any test invocation, bloop will:

1. trigger the compilation of foo and all projects depending on foo (with their dependencies)
2. run tests of foo and all projects depending on foo (without their dependencies)

Using --cascade is a powerful trick to compile or run the tests of all projects that could be
possibly affected by a change in a project. As this is a common use case, --cascade aims to
simplify its use. This feature is fully documented by the
Quickstart page.

Cancel compilation

Compile cancellation was not yet supported by bloop and v1.2.0 fixes it. Just as the cancellation
of test or run, every time the user presses Ctrl+C in the middle of a
compilation command or a bsp client sends a cancel request, bloop will cancel the compilation
gracefully.

It's highly recommended to be on the last Scala 2.12.8 release to get more predictable and quick
cancellations.

Pass jvm options to test and run (#769)

Bloop v1.2.0 takes extra arguments prefixed with -J and positioned after -- and passes them to
the underlying virtual machine running an application or executing tests. Fixed by

Pass jvm options to the bloop server

Passing jvm options to the bloop server was possible but complicated in previous versions. v1.2.0
simplifies the handling of jvm options and supports configuring the virtual machine running bloop
via two mechanisms:

1. Arguments to bloop server prefixed with -J.
2. A .jvmopts file in the bloop installation directory which is read by bloop server. This is
   the recommended way to pass jvm options to the server as it's reproducible and easy to know
   what options the server was run with.

The following section documents the handling of jvm options by bloop server.

New documentation for the Build Server 📘

The Build Server reference page is a
new addition to our docs that gives an overview of what the build server is, how it can be started,
how it's installed and how it can be managed. It also contains information about how to pass JVM
options to the server.

It's recommended to read the Build Server
Reference even if you are a seasoned
bloop user.

Fixes 🐛 🔨

1. Clear diagnostics via BSP if files with problems don't exist anymore
2. Bump up supported mill versoin to v0.3.5
3. Run bloop from different disks in Windows
4. Provide autocompletions for -o and --only test invocations
5. Fix compilation of java-only projects when no scala instance is provided

Contributors 👥

According to git shortlog -sn --no-merges v1.1.2..v1.2.0, 5 people contributed to this v1.2.0
release: Jorge Vicente Cantero, tanishiking, Daniel Karch, Dario Abdulrehman and Josep Prat.

bloop v1.1.2

Install v1.1.2 🍬

If you're on Mac OS X, upgrade to the latest version with:

$ brew upgrade scalacenter/bloop/bloop
$ brew services restart bloop

Otherwise, run:

$ curl -L https://github.com/scalacenter/bloop/releases/download/v1.1.2/install.py | python
// and restart the server

Read the complete installation instructions in our Installation page.

Highlights 📚

The v1.1.2 release is mostly a bugfix release fixing some installation problems.

Fixes in installation

1. Configure a scoop-based installation for Windows Powershell users.
2. Improve the ergonomics of Windows CMD users.
3. Fix several bugs with the installation script and the nailgun script.
4. Fix a bug in the build when running gradle in Windows.
5. Improve the UX of the installation page by persisting the choices to the session storage.

Check the PR introducing these changes here.

Handling recursive dependencies gracefully

See scalameta/metals#396 for the issue that triggered work on this area. Even
if recursive dependencies is a fatal error for bloop, we still handle
gracefully and connect successfully during a bsp connection. Builds that have
problems will get:

1. An empty response to workspace/buildTargets.
2. A build/showMessage per every error found.

Contributors 👥

According to git shortlog -sn --no-merges v1.1.1..v1.1.2, 1 people contributed to this
v1.1.2 release: Jorge Vicente Cantero.

bloop v1.1.2-M1

Merge pull request #758 from scalacenter/topic/weak-cyclic-dependency…

bloop v1.1.1

Install v1.1.1 🍬

If you're on Mac OS X, upgrade to the latest version with:

$ brew upgrade scalacenter/bloop/bloop

Otherwise, run:

$ curl -L https://github.com/scalacenter/bloop/releases/download/v1.1.1/install.py | python

Read the complete installation instructions in our Installation page.

Highlights 📚

New documentation website!

Bloop has now a new website based on Docusaurus. The new website has
simplified the installation sections and reorganized the structure to make it easier to read.

The new website is not yet finished but it's already an improvement over our old Kube-based website.

Running the server with the right Java version in Mac OS

The homebrew installation doesn't fail anymore if users have both Java 8 and Java 11 installed.
The fix consists in resolving the bloop server via coursier launch and finding the Java 8 home
by using /usr/libexec/java_home in Mac OS.

See #747.

Show a more concise output for bloop about

The output of bloop about is more concise in v1.1.1, imitating that of build tools such as yarn.

Contributors 👥

According to git shortlog -sn --no-merges v1.1.0..v1.1.1, 1 people contributed to this
v1.1.0 release: Jorge Vicente Cantero.

bloop v1.1.0

Install v1.1.0 🍬

If you're on Mac OS X, upgrade to the latest version with:

$ brew install scalacenter/bloop/bloop

Otherwise, run:

$ curl -L https://github.com/scalacenter/bloop/releases/download/v1.1.0/install.py | python

Read the complete installation instructions in our Installation page.

What is bloop

Bloop is a Scala build server and command-line tool to make the compile and test developer
workflows fast and productive in a build-tool-agnostic way. Learn more about Bloop and its origins
in this ScalaDays Berlin talk.

Highlights 📚

Build Server Protocol 2.0

The new version of the protocol, a joint effort of Olafur Páll Geirsson (Scala Center),
Justin Kaeser (JetBrains) and Jorge Vicente Cantero (Scala Center), simplifies client
integrations, improves task notifications and diagnostics reporting, adds a new BSP connection
protocol to discover BSP servers and polishes v1.0.0.

Despite the fact that there is not a stable BSP v2.0 release out yet, Bloop adds initial support
for BSP v2.0.0-M2, which is also implemented by IntelliJ 2018.3.504 and Metals 0.2.3. This means
you can use bloop v1.1.0 with both Metals and IntelliJ.

Full support for BSP 2.0 (for example, testing and running via the protocol) will soon be
available in future bloop versions.

New editor integration: Metals

Build import and compiler diagnostics in Metals are powered by bloop v1.1.0. This release adds a
lot of small usability and correctness fixes to make bloop a fitting server for Metals. Metals
supports several editors (such as vim and Visual Studio Code) and has best-in-class bloop
integration (for example, every time there is a change in an sbt build, Metals can ask you to
reload the build and run bloopInstall automatically). Try out Metals
here.

Experimental build pipelining

Build pipelining is a compilation performance technique to start the compilation of modules in
a build before their dependencies have finished compilation. An experimental implementation of
build pipelining has been pioneered and merged in bloop v1.1.0.

How to use build pipelining

Build pipelining is not yet ready for mainstream use (incremental compilation is not supported yet).

However, v1.1.0 adds experimental support to allow bloop clients check compilation speedups with
build pipelining. To benchmark build pipelining, bloop clean your project and add --pipeline
to your bloop compile invocation. Clean and repeat the process to warm up the compiler as many
times as the compilation numbers you have for raw compilation.

No incremental compilation

At the moment, build pipelining doesn't work with incremental compilation so it's not a great fit
for day-to-day use. Improvements on this area are staged for the future.

Performance results

Bloop compiles its community build successfully under build pipelining. The community build
includes the following projects: apache/spark, lihaoyi/utest, scala/scala, ornicar/lichess,
twitter/scalding, akka akka, twitter/finagle, sbt/sbt, twitter/algebird,
twitter/scalatra, guardian/frontend, netflix/atlas and guardian/grid.

The results of build pipelining are positive but are not yet fully confirmed. Compilations of
projects such as apache/spark, twitter/finagle and ornicar/lila give significant speedups.
There are reasons to think future versions of bloop and Scala (2.12.8 and 2.13.0) will improve the
performance of build pipelining. You can see that current results range from 0% to 32% compilation
speedup.

Java and Scala order

When build pipelining is run on projects that define Java and Scala sources, build pipelining
becomes more challenging. The current bloop implementation handles this transparently to the user
and defaults on a reasonable policy that works in our current community build. The downside is
that users don't have a lot of flexibility in using build pipelining and making sure it works in
their project without source changes.

In next versions, this limitation will go away and there will be an explicit mechanism for users
to control the order in which Java and Scala are compiled and its intra-build dependencies.

Test Scala.js projects

Thanks to #706, contributed by @tindzk and
@jvican, bloop v1.1.0 can now test Scala.js 0.6.x and 1.x projects and link projects
using CommonJS modules. After this change, the only missing bit is to test Scala Native projects.

A new Gradle integration

Thanks to Daniel Silva and Daniel Vigozovsky, bloop features a Gradle installation. To learn how to use bloop with Gradle, head to the installation instructions.

Improvements since 1.0.0

1. Watch changes in single files
2. Remove default dependency between test sources in sbt
3. New additions to our community build
4. Add better feedback if configuration directory is missing
5. Make compile watch clear screen before first run
6. Improve benchmarks infrastructure with
   async-profiler
7. Enable benchmarks for more projects
8. Speed up build loading and minimize its IO
9. Clean all projects by default
10. Print error if download fails in install.py
11. Add support for local homebrew formulas
12. Apply system properties to all test frameworks
13. Don't fail bloopInstall on builds of one single sbt plugin
14. Add --debug parameter to control verbosity of logs
15. Support proxy in coursier integration
16. Allow to run externally-defined main classes
17. Terminate processes gracefully
18. Handle build load errors gracefully in the server
19. Add resources to the configuration file
20. Create target path of -h ScalaTest option
21. Add fish tab completion capabilities
22. Use another hash code for projects
23. Add tests for running dependent main
24. Prove transitive resources are used in aggregated projects
25. Set cwd to project's base directory
26. Set jvm proxy from client environment variables
27. Fix test resource behavior for source-based projects
28. Improve compilation reporting to users
29. Propagate main class in sbt plugin

Improvements on the Build Server Protocol implementation

1. Use bsp 1.0.0 and implement its new methods
2. Allow bloop reflective invocation with cancellation
3. Don't error on trace message
4. Upgrade to latest bsp version
5. Upgrade to bsp 1.0.1 to use status code
6. Reload and save state during BSP actions
7. Publish diagnostics for syntax errors and improve tests
8. Return correct platform for BSP Scala targets
9. Re-publish diagnostics for warnings
10. Migrate to bsp 2.0.0 partially
11. Re-publish all warnings on BSP server startup

Contributors 👥

According to git shortlog -sn --no-merges v1.0.0..v1.1.0, 17 people contributed to this
v1.1.0 release: Jorge Vicente Cantero, Martin Duhem, Tim Nieradzik, Daniel Silva, Paweł
Bartkiewicz, Daniel Vigovszky, Josep Prat, Etienne Couritas, Jens Grassel, Martin Mauch, Qi Wang,
Ashwin Raja, David Francoeur, Kevin Rauscher, Octavian Genes, Reto Habluetzel, fanconepl, ioleo.

The core team is grateful to all the contributors that have submitted PRs and helped
improved the documentation of Bloop. Thanks a lot!

bloop v1.0.0

Install v1.0.0 🍬

If you're on Mac OS X, upgrade to the latest version with:

$ brew install scalacenter/bloop/bloop

Otherwise, run:

$ curl -L https://github.com/scalacenter/bloop/releases/download/v1.0.0/install.py | python

Read the complete installation instructions in our Installation page.

What is bloop

Bloop is a Scala build server and command-line tool to make the compile and test developer
workflows fast and productive in a build-tool-agnostic way. Learn more about Bloop and its
origins in this ScalaDays Berlin talk.

Initially as an idea by Martin Duhem, Bloop has iterated into its design several times and
materialized into a stable compile/test server that people from different build tools can leverage to
have a faster developer workflow.

We're in debt with the people that have believed in the project, adopted Bloop and joined our
developer team in the early days, most notably @tues,
@fizzy33, @rberenguel,
@propensive,
@lefou and @tindzk.

Bloop v1.0.0 is just the beginning. The next v1.1.0 release will keep focusing on developer
productivity and feature more speedups in compilation. Stay tuned.

Highlights 📚

A new configuration file format

The configuration file format is a JSON file that describes the configuration of your project.
It contains a subset of all the configuration keys required to compile, test and run your project
like the project name, source directories, classpath and the like.

Bloop configuration files are easy to generate, easy to read and easy to modify. Bloop keeps a
strict forward and backward compatibility on the source files in every major version so that
whatever tooling that you build on top of them keeps running in your computers.

Compile, test and run your projects quicker!

After you have exported your build to Bloop configuration files, Bloop can compile, test and
run your projects quicker than any other build tool. Bloop can compile your projects around 20-30%
faster than sbt.

Generate bloop configuration files from sbt, Maven and mill

There are plugin integrations for sbt, Maven and mill that generate configuration files
when the task bloopInstall is executed. These integrations allow you to use Bloop for these build
tools.

A gradle plugin integration is coming and will be
merged into 1.1.0.

Compile and run Scala Native and Scala.js projects

Run your Scala Native and Scala.js projects with Bloop. If your build tool supports Scala Native
and Scala.js (like sbt), Bloop's integration will automatically create projects for your Scala
Native and Scala.js projects. Support for tests and incremental linking is left as future work
for 1.1.0.

Improvements since 1.0.0-RC1

Log output of server in OSX services (plists)

The Homebrew formulas now installs plist services that will log stdout and stderr to Bloop's log
directories /var/log/bloop.

Upgrade to NuProcess 1.2.4

Running Bloop projects in JDK 10 didn't work because NuProcess failed to link with the new
process API in JDK 10. Upgrading to the last NuProcess version fixes this issue.

Remove --isolated flag and add --propagate / --include-dependencies

The flag --isolated has been removed because it was not a good default. In most of the cases,
users want to clean and test a project in isolation, and propagate that to all their dependencies
only in concrete cases.

As a result, a new flag --include-dependencies (aliased to --propagate) has been added to
the CLI test and clean commands.

Remove --parallelism flag in bloop configure

Remove the --parallelism alias of --threads to avoid confusion with the future parallel
compilation configuration settings that will be merged in 1.1.0. Use --threads instead.

Complete changelog

v1.0.0 is a release that contains changes that span almost half a year. To fully catch up
with all the changes that have gone into the creation of v1.0.0, we redirect users to the
release notes of all our previous versions.

1. v1.0.0-RC1
2. v1.0.0-M11
3. v1.0.0-M10
4. v1.0.0-M9
5. v1.0.0-M8
6. v1.0.0-M7
7. v1.0.0-M6
8. v1.0.0-M5
9. v1.0.0-M4
10. v1.0.0-M3
11. v1.0.0-M2
12. v1.0.0-M1

Contributors 👥

According to git shortlog -sn --no-merges v1.0.0-M11..1.0.0-RC1, 27 people contributed to this
v1.0.0 release: Jorge Vicente Cantero, Martin Duhem, Paweł Bartkiewicz, Ruben Berenguel Montoro, Tim Nieradzik,
msvaljek, Jon Pretty, Jorge, Andrew Valencik, Gabriele Petronella, Olivier Mélois, Sam Halliday,
David Barri, Alexander Samsig, travisltq, Alexey Alekhin, Emilien Taque, Eugene Platonov,
Guillaume Massé, Justin Kaeser, Olivier Melois, Pawel Bartkiewicz, Samantha Li, Sean Sullivan,
Stephen Nancekivell, Tobias Roeser and shamsak58.

The core team is grateful to all the contributors that have submitted PRs and helped
improved the documentation of Bloop. To a faster developer workflow! 🥂