Backport build changes and TASTy version tests from main #185
Conversation
…cala#21837) * Introduce `developedVersion` describing the target for the current release cycle * Adapt `baseVersion` to the effectively revert scala#21011 changes * Adapt .msi packager to use `developedVersion` as a workaround to MSI ProductInfo limitations (version without RC suffix required) * Group and document versioning related code
…#22187) * We now document better how and when tasty version should be set * Add additional runtime test to ensure we don't emit invalid TASTy version during Release / NIGHTLY releases and the expected version set in build matches version defined in TastyFormat
…e released using stable TASTy version
| * - in release candidate branch is experimental if {patch == 0} | ||
| * - in stable release is always non-experimetnal | ||
| */ | ||
| val expectedTastyVersion = "28.3" |
There was a problem hiding this comment.
I think we were once discussing that TASTy version of all nightlies, including LTS nightlies, should be experimental. However it's not so obvious which version of TASTy format should be used in such case.
In Scala Next that would be 28.{minorVersion + 1}-experimental-1 (assuming patch > 0), however such schema cannot be used for LTS - TASTy 28.4 already exists and is stable.
We can potentially use 28.3-experimental-2 but it also seems to not make sense becouse 28.3 is already stabilised.
In such case I think it's best to assume that LTS always emits stable TASTy. It should be fine, becouse every backported change is carefully checked and tested in both Scala CI and OpenCB before merging which should detect potential issues
There was a problem hiding this comment.
I'm quite tempted to say that from TASTy's perspective we should treat LTS as any other minor version series. In theory we could also have nightly versions and backport PRs to 3.4, 3.5, etc. but we don't do that just because we don't have enough resources to manage that
There was a problem hiding this comment.
I'm quite tempted to say that from TASTy's perspective we should treat LTS as any other minor version series.
Totally agree
The main problem here comes from versioning, especially because we do actually release LTS nightlies. However, the versioning schema of TASTy seems to not be compatible with our needs.
With version 28.3-experimental-2 we'd get into issue in non-bootstrapped tests - these require that reference version of compiler has version in range 28.0 - 28.2 or exactly the same version experimental TASTy 28.3-experimental-2. We use 3.3.5 producing Tasty 28.3 which would not fit the required version bounds.
Unless you're suggesting to use 28.4-experimental-1 which would make the non-bootstrapped tests happy. Is it what you're refering to?
There was a problem hiding this comment.
We can potentially use 28.3-experimental-2 but it also seems to not make sense becouse 28.3 is already stabilised.
But what versions do we use normally? If we have 28.7 tasty currently being release, what will be the Scala 3 nightlies have as tasty version? 3.6.2 has 28.7 and 3.6.3 has 28.7, what did the nightlies between have as tasty version?
There was a problem hiding this comment.
Scala 3.3 LTS uses 28.3 for both RC and nightlies
Scala 3.4.0 uses 28.4 for stable and 28.4-experimental-1 for RC and nightly
Scala 3.4.1 uses 28.4 for RC/stable and 28.5-experimental-1 for nightlies
I think we can skip potential change to TASTy LTS versions for the future. Currently we'll continue to use existing schema - always stable TASTy
TastyVersion- required for backported TASTy tests