3.3.2 release thread

Congrats on the release! I put this on Discord, but per @SethTisue’s advice I’ll stick it on here as well.

Do you think it’s be possible for Dotty to use Milestones on GitHub and mark PRs with a milestone? With having LTS and also Next it’s a bit hard at times to understand what will end up where. For example I just checked the new coverage filtering to see where it would end up Port coverage filter options for packages and files by KacperFKorban · Pull Request #19727 · lampepfl/dotty · GitHub and I do see that it was in the 3.lts backports but it doesn’t tell me if that’s included in 3.3.3 or it will first be 3.3.4. Using milestones is a really nice way to signify to users where exactly something will end up. Mill does a nice job of this if you want an example Update example `build.sc` with current library versions by cstroe · Pull Request #3055 · com-lihaoyi/mill · GitHub – like I can clearly see this change will land in 0.11.8 and it’d be great to have this same sort of clarity when looking at PRs on Dotty.

6 Likes

It occurs to me just now that it’s a bit tricky because GitHub only lets you give an issue or PR a single milestone, but for Scala 3, you’d want to know what LTS release it’s landing (or landed) in, and what non-LTS release. :thinking:

Is it safe to assume that whenver the next version is for each line, when a PR comes in, those are the ones it will land in? I could see something like this with milestones:

  • 3.3.4 / 3.4.1
  • 3.4.1
  • 3.3.4

Would just having three like this work?

All things that are in any released version are assigned to that milestone. If they are later backported to the LTS, the milestone is changed to 3.3.x. If something is without milestone, it should be treated as an result of a bug in release scripts.

1 Like

For LTS/Next, I think it makes more sense to use a Tag on the PR (which you can have more than one)