-
Couldn't load subscription status.
- Fork 1.9k
Document the procedure of upgrading to the new Kotlin version #4557
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,38 @@ | ||
| # Checklist for upgrading to the new Kotlin version | ||
|
|
||
| 1. Create a new branch based off `develop`: | ||
| ```sh | ||
| git fetch | ||
| git checkout -b kotlin-<version> origin/develop | ||
| ``` | ||
|
|
||
| 1. In `gradle.properties`, | ||
| set `kotlin_version` to the `<version>`. | ||
|
|
||
| 2. Likewise, set `kotlin_version` in `integration-testing/gradle.properties`. | ||
|
|
||
| 3. In `README.md`, | ||
| replace the occurrences of the old version with the `<version>`. | ||
| These are: | ||
| - A badge at the top of the file. | ||
| - The Kotlin version corresponding to the latest release, | ||
| mentioned in the first paragraph. | ||
| - Maven and Gradle configuration blocks. | ||
|
|
||
| 4. In `README.md`, find the link to https://pl.kotl.in/ and open it. | ||
| Set the compiler version of Kotlin Playground to the same major version as `<version>`, | ||
| click "Copy link", and replace the original link in `README.md` with the new one. | ||
|
|
||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Add: Search for There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The idea is good. It would bring the most utility if we adopted a machine-searchable unified comment format for this, like There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sounds good! Though, avoid "TODO", since TODOs are reported by Idea and they are not actionable if they are blocked by a version. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Also: "remove after", "fix in", etc. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Also, we usually say "after old version", not "after new version", so we need to search for the old version as well There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. "fixed", "workaround" There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Created an issue to cleanup all those workarounds. Hopefully we will remember to comment them correctly and search for them after upgrading. |
||
| 5. Perform a full build: `gradle clean check publishToMavenLocal`, | ||
| followed by `gradle clean check` in the `integration-testing` directory. | ||
| Fix any issues that arise. | ||
|
Comment on lines
+26
to
+28
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Shall we have a separate mini page / section about building the project locally?
Rather than I don't know if this is obvious gradle 101, but since we are documenting everything anyway, why not. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. How about we keep it as is right now, and I'll do a proper build page later? This is mostly a mac issue, and I assume you don't really use mac. I was going to reinstall my mac anyway, I'll document everything I need to install to build kotlinx.coroutines locally on mac. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It did require me to install the emulator, though. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, I understand that, my point is, everyone attempting to build any Kotlin library that has tvOS as a target will also have to install the emulator, this is not unique to There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If a user is using tvOS with Kotlin/Native, they will know that they should install the emulator. The problem here is that a user might want to run the test suit, which runs tests for everything, and it is unique to our library (and other first-party kotlin libraries). I'm happy to do a build page for all our first-party libraries, but I disagree that it should belong to the "Get started with Kotlin/Native". There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
That's the case for any KMP library, and libraries supported by JetBrains are not special in that regard. Thus setting up an environment to build and execute multiplatform code is a part of Kotlin/Native setup and the proper place to provide guidance on setting it up are K/N docs. If build fails due to missing emulator, but it is not clear from provided diagnostic messages, then build tools should be improved to make it clear for a user. |
||
|
|
||
| 6. Commit and push all changes to GitHub: | ||
| ```sh | ||
| git commit -am 'Upgrade to Kotlin <version>' | ||
| git push -u origin kotlin-<version> | ||
| ``` | ||
|
|
||
| 7. Wait for the TeamCity continuous integration builds to finish. | ||
|
|
||
| 8. Open a new pull request, receive approval, and merge. | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AFU has a script automating the version-replace step (but its about AFU-version, not a Kotlin version it depends on), you can reuse it, if you see a value in that: https://github.com/Kotlin/kotlinx-atomicfu/blob/master/bump-version.sh
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have our own, improved version of that script: https://github.com/Kotlin/kotlinx.coroutines/blob/master/bump-version.sh If you want, I can make a PR to atomicfu and port the improvements.