chore: decide the Dart SDK floor before very_good_analysis 11.0.0 can be adopted (consumer-facing for a published CLI)

[riker-wamf]

very_good_analysis 11.0.0 requires Dart SDK ^3.13.0. This repository declares environment: sdk: ^3.10.0 and pins Dart 3.10.0 in CI, so the major upgrade cannot be installed here. Dependabot opened the bump as #48.

Measured evidence

Place	Current value
pubspec.yaml	environment: sdk: ^3.10.0
.github/workflows/dart_slack.yaml:38 (build job)	sdk: "3.10.0"
.github/workflows/dart_slack.yaml:61 (verify-version job)	sdk: "3.10.0"

very_good_analysis version floors, read from pub.dev:

Version	Required SDK
10.1.0	^3.10.0
10.2.0	^3.11.0
10.3.0	^3.12.0
11.0.0	^3.13.0

The newest version that resolves on Dart 3.10.0 is 10.1.0. The current constraint is ^10.1.0, so the repository already resolves the newest version its own toolchain permits.

Why this is a product decision, not a chore

dart_slack is a published package. It declares repository:, topics: and an executables: entry. Raising environment: sdk from ^3.10.0 to ^3.13.0 drops support for anyone who installs the CLI on Dart 3.10, 3.11 or 3.12. That needs a CHANGELOG.md entry and a version bump before the next publish. The benefit is a development-only lint and format configuration, so the cost is larger than the gain until the team decides to move the floor.

The trap to avoid

Do not widen the constraint across the major boundary. PR #48 proposed ">=10.1.0 <12.0.0". That shape is unsafe here, and artis-wamf measured why:

• The upstream analysis_options.yaml sets formatter: trailing_commas: preserve in every 10.x release and formatter: trailing_commas: automate in 11.0.0.
• dart format reads the formatter: key, so the two settings produce different output for the same source file.
• There is no pubspec.lock in this repository, so nothing pins the resolved version.

A contributor on Dart 3.13 would resolve 11.0.0, format locally, and push. CI on Dart 3.10.0 resolves 10.1.0 and runs dart format --set-exit-if-changed ., so the job fails. The next person to push an unrelated commit sees a red build they did not cause. Keeping the constraint inside one major version gives every machine one identical configuration.

Issue #40 already records a related instance of the same class of problem: the format gate result depends on the SDK version.

Interim state

A semver-major ignore entry for very_good_analysis is added to .github/dependabot.yml, so the unresolvable bump stops reappearing. This matches the entry already in use in WAMF/dartdoom for the same package and the same reason.

What closes this issue

• Decide whether dart_slack may require Dart 3.13. This is the blocking decision and it belongs to whoever owns the published package.
• If yes: raise environment: sdk to ^3.13.0, raise both setup-dart pins, move the constraint to ^11.0.0, and apply what the 3.13 formatter and the 11.0.0 rule set require. Use the single-variable control recorded in the shared FAQ under question ts705r538ph5ns5t15t62qyd858dt06p, so the change is proved complete and free of unrelated edits.
• Add a CHANGELOG.md entry and bump the version, because the SDK floor is consumer-facing.
• Answer issue CI's dart format gate is SDK-version dependent: lib/src/slack.dart is unformatted under Dart >= 3.11 #40 in the same change, or record that the format gate stays SDK-dependent.
• Remove the ignore entry.

[riker-wamf]

I searched the FAQ and asked Lee to confirm the SDK decision: Dart 3.13 at the next minor release.

The recommendation includes a CHANGELOG entry and a minor version bump. It ends support for new installs on Dart 3.10 to 3.12. No SDK floor change has been made.

The implementation task is blocked on this answer. It will start when Lee answers. It requires one PR, Kumar and Data reviews, and both CI jobs. It will not merge or publish to pub.dev.