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
- move intellij-plugin-with-experimental-shared-base into experimental examples (it still on Compose 1.0.0)
- remove usage of deprecated DesktopTheme
- add `[examples](experimental/examples)` to the main page
- move screenshot into screenshots folder
- add Readme, run configuration, .gitignore to web-template
- fix web-compose-in-js (read versions from properties)
- add global idea/ into gitignore
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.