JS target supports a lower version (1.7.10), because we have a bug in Koltin 1.7.20
Compose 1.2.0 will support:
1.7.20 and 1.7.10 for Android and Desktop
1.7.10 for JS
We will release the new patchset (1.2.1) with 1.7.2X support for JS later
By default, the Compose Multiplatform Gradle plugin
uses `org.jetbrains.compose.compiler:compiler:<COMPOSE_VERSION>`
as a compiler plugin .
However, a new version of Kotlin might be incompatible with
the default version of compiler plugin. Previously, that forced
users to update to a new version of Compose Gradle plugin & Compose libraries
in order to use a new version of Kotlin. Accordingly, Compose framework developers
had to release a new version of all libraries, when a new version of Kotlin is released.
Some time ago the Compose team at Google made it possible to update a compiler plugin
without updating the Gradle plugin and/or all Compose libraries
https://developer.android.com/jetpack/androidx/releases/compose-kotlin
This change allows to specify a custom compiler artifact by using the following DSL:
```
compose {
kotlinCompilerPlugin.set("<VERSION<")
// or
kotlinCompilerPlugin.set("<GROUP_ID>:<ARTIFACT_ID>:<VERSION>")
}
```
* move to kotlin 1.6.10-RC and corresponding compose commit
* Update path to the karma plugin we are patching
* Add ExperimentalComposeWebStyleApi
what worries me that this actually shows that there are some cases where without any changes apart version compiler people will have to worry about such annotations
* update kotlin version in templates to adopt 1.6.10-RC
* web: move ComposableWithNullableTypeParameter.kt to passing test cases
* update kotlin version in other places
* update imageviewer example: add OptIn for experimental API
* move compose
* move to kotlin 1.6.10 and corresponding compose
* move to kotlin 1.6.10 and corresponding compose
* move to 1.0.1-rc2
* move to 1.0.1-rc2 (todoapp)
Co-authored-by: Oleksandr Karpovich <oleksandr.karpovich@jetbrains.com>
Co-authored-by: Shagen Ogandzhanian <shagen.ogandzhanian@jetbrains.com>
Remove:
```
__LATEST_COMPOSE_RELEASE_VERSION__
__KOTLIN_COMPOSE_VERSION__
System.getenv("COMPOSE_TEMPLATE_COMPOSE_VERSION")
```
They pollute templates/examples.
Now, all paths where we need to change the version are hardcoded in the script.
Usage:
```
./replace.sh 1.0.0-rc6
```
This script is planned to run on CI
In the future I will add support for changing Kotlin version
* Tests stopped compiling after preview RPC was embedded,
because compileOnly dependencies are not visible to tests;
* Local test runs were broken, because the default
compose.version (1.0.0-alpha4-build328) is not compatible
with Kotlin 1.5.31 (compose.version is always overridden on CI,
so CI runs work);
The build `0.4.0-build182` upgrades
`kotlinx-collections-immutable` library
(which is used by the compose runtime) to 0.3.4,
which was published to maven central,
so most usages of sunsetting jcenter repo
can be removed now.
Resolves#557
There are two versions used in the Gradle plugin:
* The version of the plugin itself;
* The version of Compose dependency used by the plugin.
On CI both versions are set to the same value specific to the build.
However, locally using 0.1.0-SNAPSHOT for the Compose version is inconvenient,
because we don't publish 0.1.0-SNAPSHOT anywhere.
Even if it existed, a moving version is not convenient for using in tests.
This commit changes version handling:
* The version of Compose is set via `compose.version` Gradle property
to the latest stable version, unless overridden by
`COMPOSE_GRADLE_PLUGIN_COMPOSE_VERSION` env. var.
* The version of the plugin is set via `deploy.version`
Gradle property to 0.1.0-SNAPSHOT,
unless overridden by `COMPOSE_GRADLE_PLUGIN_VERSION` env. var
Igor Demin
Igor Demin
Alexey Tsvetkov
Nikolay Igotti
Oleksandr Karpovich
Nikolay Igotti
Alexey Tsvetkov