Set the default version to 9999.0.0-SNAPSHOT, pin all dependencies #1696
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
MatkovIvan
reviewed
Nov 27, 2024
| // project("compose:ui") -> lifecycle-runtime-compose:2.8.4 -> compose.runtime:runtime:1.6.11 | ||
| // project("compose:ui") -> project("compose:runtime") | ||
| // project("compose:runtime") should override compose.runtime:runtime:1.6.11 by default | ||
| "9999.0.0-SNAPSHOT" |
There was a problem hiding this comment.
It seems too dangerous for me.
Move versioning from CI to
libraryversions.toml
Sounds much better
igordmn
changed the title
|
Figure out an easy way to publish 9999.0.0-SNAPSHOT:
I will add a check for this, as the alternative (moving versioning from CI) requires 8x more time |
…e UI to 2.8.4 These are preparation to build Compose 1.8.0-alpha01 from `jb-main` branch. 1. Set the default version to 9999.0.0-SNAPSHOT. It is needed for pinning, more in the code comment. **Alternative** Move versioning from CI to `libraryversions.toml`. It will contain all next versions we need to publish, and they are always greater than the pinned versions. This requires some work and I didn't plan it in the short term. **Disadvantage** We can accidentally publish it to the dev repo. But users won't see it in the suggestions because it is `-SNAPSHOT`. This is also true for the alternative, so we have this disadvantage anyway. 2. Pin lifecycle to `2.8.4` in `jb-main` branch **Alternatives** - Change jetbrains.publication.version.LIFECYCLE=2.8.4 in gradle.properties (an option, but there is no verification that it uses the correct API) - Don't pin, depend on the project version, which should be 2.9.0-alpha01 (but we need to publish Lifecycle, and CI for it is WIP) - Create `release/1.8.0-alpha01`, pin there (doesn't work, because the current release process requires version increasing in the main branch after we create a `release` branch, to maintain ordering of release/dev builds) **Disadvantages** - "Go to definition" goes to the 2.8.4 library sources instead of the project sources. - Can't use/test new changes in Lifecycle Proper pinning guidelines proposal is WIP at the moment, we can discuss it later, and for now, agree on a working solution for 1.8.0-alpha01. ## Testing 1. Build ``` ./gradlew publishComposeJbToMavenLocal -Pjetbrains.publication.version.COMPOSE=1.8.0-test1 -Pjetbrains.publication.libraries=COMPOSE ``` 2. Check module files 3. Sync and run the version on the desktop template: - lifecycle should be 2.8.4 - runtime should be the same that was built
Not pinned dependencies: - collection (new API needed) - core (new lib core-uri) - shapes (no stable version)
Not pinned dependencies: - collection (new API needed) - core (new lib core-uri) - shapes (no stable version)
igordmn
force-pushed
the
igor.demin/pin-lifecycle-in-compose
branch
from
bc9a167 to
1f0684d
Compare
|
@MatkovIvan, could you look at the current state, so we able to merge it today?
|
|
It seems it was flaky |
MatkovIvan
approved these changes
Dec 2, 2024
MatkovIvan
pushed a commit
that referenced
this pull request
Dec 12, 2024
…1696) These are preparation to build Compose 1.8.0-alpha01 from `jb-main` branch. 1. Set the default version to 9999.0.0-SNAPSHOT. It is needed for pinning, more in the code comment. **Alternative** Move versioning from CI to `libraryversions.toml`. It will contain all next versions we need to publish, and they are always greater than the pinned versions. This requires some work and I didn't plan it in the short term. **Disadvantage** We can accidentally publish it to the dev repo. But users won't see it in the suggestions because it is `-SNAPSHOT`. This is also true for the alternative, so we have this disadvantage anyway. 2. Pin all dependencies to be able to not release them. Not pinned dependencies: - collection (new API needed) - core (new lib core-uri) - shapes (no stable version) ## Testing 1. Build ``` ./gradlew publishComposeJbToMavenLocal ``` 2. Check module files 3. Sync and run the version on the desktop template 4. run1, runDemo # Conflicts: # compose/animation/animation-core/build.gradle # compose/foundation/foundation-layout/build.gradle # compose/foundation/foundation/build.gradle # compose/material/material/build.gradle # compose/runtime/runtime/build.gradle # compose/ui/ui-graphics/build.gradle # compose/ui/ui-test-junit4/build.gradle # compose/ui/ui-test/build.gradle # compose/ui/ui-text/build.gradle # compose/ui/ui-unit/build.gradle # compose/ui/ui/build.gradle
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
These are preparation to build Compose 1.8.0-alpha01 from
jb-mainbranch.Alternative
Move versioning from CI to
libraryversions.toml. It will contain all next versions we need to publish, and they are always greater than the pinned versions. This requires some work and I didn't plan it in the short term.Disadvantage
We can accidentally publish it to the dev repo. But users won't see it in the suggestions because it is
-SNAPSHOT.This is also true for the alternative, so we have this disadvantage anyway.
Not pinned dependencies:
Testing