IDEA doesn't provide backward compatibility policy, and breaking changes can happen in any version, without prior deprecation:
https://plugins.jetbrains.com/docs/intellij/api-changes-list.html
~~Because of that, we can't remove `plugin.until.build`, and have to build Compose plugin for each new version of IDEA separately~~ (see Update)
~~Update 1:
I removed plugin.until.build anyway. In most cases there won't be a broken plugin. And if it will be broken, we will know it during IDEA EAP. Considering this, better when users don't wait the new version, and use already available one.~~
Update 2:
If we omit plugin.until.build, then it has default value +8. Returned, but made the default value big enough.
What we should do after that commit, is make sure, that we don't forget to check this compatibility. And ship a new stable version for every new stable IDEA.
The ideal way is to run `runPluginVerifier` on CI for the latest version, which will fail the build, if our plugin isn't compatible.
But for some reason, there is no EAP for IDEA 2022.3 here:
https://jb.gg/intellij-platform-builds-list
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
ProGuard support has introduced `Release` build type in addition to the default one.
Prior to that there was the `package` task, which did not do anything by itself.
The `package` task existed purely for convenience: instead of running
the `packageMsi` on Windows and the `packageDmg` on macOS, a user could
run the `package` task to package an application into a format suitable for a host OS.
A similar task for the release build type should be called `packageRelease`.
However, this name conflicts with a task created by the `com.android.application`
plugin.
This change deprecates the `package` task and removes the `packageRelease` task.
`packageDistributionForCurrentOS` and `packageReleaseDistributionForCurrentOS` should be used instead.
Resolves#2345
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>")
}
```
* Add a mention in the packaging tutorial about Conveyor, with a feature comparison on a separate page.
Remove the link from the main page to the signing/notarization tutorial as it's already linked to from the main packaging tutorial in any case.
* Address review comments.
- Don't talk about jpackage.
- Put the features of the built in tasks first on the comparisons page.
- Remove discussion of JNI.
Additionally:
- Reformat the feature list so the summary comes first in bold.
- Point out that the feature list isn't complete.
* Add NO_SKIKO platforms set in ComposePlatforms
They can be used to build and publish compose-runtime.
Other compose modules can't be built for NO_SKIKO since those platforms are not supported by skiko yet.
* Fix typi
Co-authored-by: dima.avdeev <99798741+dima-avdeev-jb@users.noreply.github.com>
Co-authored-by: Oleksandr Karpovich <oleksandr.karpovich@jetbrains.com>
Co-authored-by: dima.avdeev <99798741+dima-avdeev-jb@users.noreply.github.com>
* web: Support for transition in CSS api.
* Use proper name for Transitions class, fix formatting.
* web: add ExperimentalComposeWebApi on transitions CSS API.
* web: Add documentation for transitions CSS API.
* fix: Apply all suggested changes.
* web: Add unit tests to transitions CSS API.
* fix: Update documentation with new methods names.
* Temporary deprecate 3 overloads of StyleScope.borderWidth
The reason is wrong parameter names. The behaviour is still correct.
The idea is to fix the parameter names in 2.0 (which is more appropriate for breaking changes)
* Apply better deprecation and replacement approach
* improve the deprecation message
* fix
* add tests for deprecated borderWidth
Co-authored-by: Oleksandr Karpovich <oleksandr.karpovich@jetbrains.com>
Alexey Tsvetkov
Igor Demin
Oleksandr Karpovich
Igor Demin
Igor Demin
Oleksandr Karpovich
Mike Hearn
Ahmed MJ
Omico
dima.avdeev
Ayfri
Philip Wedemann
Emir
Veyndan Stuart
walfud
dima.avdeev
theapache64