build_web_compilers shouldn't have an upper SDK bound.

[sortie]

Somebody needs to fix build_web_compilers so it doesn't have an upper sdk limit because it blocks our ability to make releases. Right now if we bump the sdk version, the test will fail, blocking out ability to update the sdk version after cutting a stable release.

The tests

pkg/dartdev/test/commands/create_integration_test RuntimeError (expected Pass)

are failing on configurations

unittest-asserts-release-linux

https://logs.chromium.org/logs/dart/buildbucket/cr-buildbucket/8768040075748241681/+/u/test_results/new_test_failures__logs_

[jakemac53]

The upper bound isn't just there for no reason... we have a somewhat tight upper bound as an agreement with the web compiler team, because it allows those tools (and others) to make breaking changes to their command line arguments, etc.

If we are notified in advance of the version change, we could pre-emptively bump the max SDK limit ahead of time?

[jakemac53]

New versions have been published that allow 3.3.x, not closing this for now though since I think there is more discussion to be had for future releases.

[jakemac53]

Fwiw - we have a similar situation with dart_internal. So whatever process we have for that package could be also used for these packages? For macros we also plan to have another package that will be tightly constrained to SDK versions.

[sortie]

Thanks for the quick answers. Yeah we'll definitely need to have solutions here and I'm happy to help find them :)

Because right now it can be pretty impossible to start work on the next dart version and we need to significantly reduce issues like this

[jakemac53]

I am definitely happy to do a pre-emptive bump. It typically should not take more than a day of turnaround time. I just don't know how to coordinate that with the releases.

These pre-emptive version bumps could go out even a couple weeks before the actual release.

[sortie]

go/dash-team-releases has a lot of information and a spreadsheet where you can register yourself for action items that must be taken during a release. :)

Once the 3.3 bump goes through, I'll learn more about the classes of problems that people need solved and try to make this process easier for everyone :)

[jakemac53]

I added a row to the release checklist template under the dart_internal bump

[jakemac53]

Is that sufficient to close this issue? Presumably I will get assigned a task for future releases?

[sigmundch]

mmm - something seems odd to me from the checklist process, I believe this needs to happen before we bump the version in the SDK, but currently we are thinking about this in terms of the release steps after the bump.

[sortie]

This is happening again for the 3.4 version bump. Please publish a version with build_web_compilers that supports 3.4 :)

@itsjustkevin I think this release step somehow didn't get onto the release instructions, can you work with these build_web_compilers folks can get into the release procedures? This should ideally happen before we do the final merge to beta, where we do the main version bump immediately after.

Can you give us a deeper explanation of why this package needs an upper sdk constraint and why alternatives aren't possible? It's a bit of an antipattern whenever packages need to do this and this package is the only such package that causes problems for our release bumps -- a process that's already too complicated and risky. You mentioned something about needing to keep the package in sync with the Dart SDK and wanting to bypass the breaking change policy. Might it be possible to build a stable interface between this package and the dart sdk, so it can learn what it needs from the Dart SDK and support future releases? The breaking change policy is something of a feature in this regard rather than a problem since it encourages us to build stable interfaces that are durable. On the other hand, if this package is that tightly coupled with the Dart SDK, then perhaps it should be developed as part of the Dart SDK? That's where we got all the other packages that need the tight coupling. I'm curious to learn more so we can simplify and derisk our release procedures :)

[itsjustkevin]

Thanks for tagging me @sortie, this may be a good time for a full review and revamp of the release checklist, as many processes have evolved.