support 3.8 pre-release sdks

[jakemac53]

@nshahan I added you as a reviewer to confirm that we don't expect any breaking changes to the dev compiler command line in 3.8?

cc @jyameo

[github-actions]

Package publishing

Package	Version	Status	Publish tag (post-merge)
package:build_modules	5.0.11	ready to publish	build_modules-v5.0.11
package:build_web_compilers	4.1.1	ready to publish	build_web_compilers-v4.1.1
package:build	2.4.2	already published at pub.dev
package:build_config	1.1.2	already published at pub.dev
package:build_daemon	4.0.3	already published at pub.dev
package:build_resolvers	2.4.4-wip	WIP (no publish necessary)
package:build_runner	2.4.15-wip	WIP (no publish necessary)
package:build_runner_core	8.0.0	already published at pub.dev
package:build_test	2.2.4-wip	WIP (no publish necessary)
package:scratch_space	1.0.3-wip	WIP (no publish necessary)

Documentation at https://github.com/dart-lang/ecosystem/wiki/Publishing-automation.

[github-actions]

PR Health

Changelog Entry ✔️

Package	Changed Files

Changes to files need to be accounted for in their respective changelogs.

[nshahan]

Because of the way these packages are so tightly coupled to the SDK versions I'm not sure what counts as a breaking change in this context. If we were to want to build web compilers to pass different arguments in 3.8 when invoking DDC does that count as a breaking change? I'm also planning on removing the --sound-null-safety at some point, possibly in 3.8 if we can ship 3.7 with it printing a deprecated warning.

[jakemac53]

If we were to want to build web compilers to pass different arguments in 3.8 when invoking DDC does that count as a breaking change?

Yes, this is exactly the kind of change that would break build_web_compilers. I think in this case though, we only support sound null safety anyways I believe, so that should be OK (I don't see us passing that flag anywhere).

[jakemac53]

Actually I just remembered we are guarding stable releases anyways because of the -z, so if build_web_compilers does get broken in some 3.8 dev release, we can just release a fix and it will be OK, it can't break 3.8 stable because we aren't declaring support yet for that.

This will in effect declare support for 3.7 stable but that should be fine, I assume the branch is now cut and any breaking changes there already would be in (modulo cherry picks which shouldn't have changes like this).