Stable branch should not be cut until the version number flips

[jakemac53]

We currently are continually having more 2.10.0-x.x.dev versions tagged in the repo, but these versions will never ever make it into a stable 2.10 release.

This opens up issues for packages that need to rely on these tags for setting their version constraints.

Case in point - I early today published a version of source_span which requires this commit. So, I looked at the tagged versions for that, and set the earliest one (2.10.0-137.0.dev) as the minimum SDK bound.

However - that commit will never appear in any stable 2.10 sdk release because it was cut before that landed. Thus, this package would be broken when 2.10 stable is in fact released (in reality though, we got lucky here that it has a <2.10.0 constraint to disallow that).

In order to ensure that these misleading tags are not present in the repo, we should bump the version first, and then we should fork 2.10 stable at the commit directly preceding the one in which the version was bumped.

I am unsure of how to categorize this issue, @athomas can you label and triage it?

[jakemac53]

cc @stereotype441

[athomas]

We've made this problem worse by not landing the version bump in a timely manner (partly due to the added complications around language versioning). @franklinyow, this is one of the reasons why I've been pushing the release checklist.

The commit will also never appear in any Dart 2.10 dev releases because they are halted until the version bump is landed (this isn't coordinated with Flutter at the moment, so it may appear in Flutter dev releases, @pcsosinski).

The current process creates not just one, but many candidates for 2.10 branchout. Bumping the version would require a freeze in Flutter rolls during candidate selection. This has other drawbacks on the Dart team that the current process removed. I realize this is a compromise, right now my opinion is that we should minimize the time we're inconsistent. This would still leave us open to one or two misleading tags, but at the same time ensure that Flutter rolls don't need to be frozen for one or two weeks.

[athomas]

Looking at the version constraint for source_span, it says: '>=2.10.0-137.0 <2.10.0' which excludes 2.10 stable releases. So I don't see how the package will be broken when 2.10.0 is released. Though, that could've happened if you'd been less careful with your constraint, so the problem is real.

[jakemac53]

Yes, in practice for source_span we got lucky that it is an nnbd prerelease and we have tight sdk constraints for that.

[jakemac53]

The commit will also never appear in any Dart 2.10 dev releases because they are halted until the version bump is landed (this isn't coordinated with Flutter at the moment, so it may appear in Flutter dev releases, @pcsosinski).

This part seems problematic as well, will those commits ship with flutter stable? Does that mean the Dart 2.10 that ships with flutter is different from the standalone 2.10 release?

[pcsosinski]

have we bumped to 2.11 yet? if not, why not?

[athomas]

The commit will also never appear in any Dart 2.10 dev releases because they are halted until the version bump is landed >>(this isn't coordinated with Flutter at the moment, so it may appear in Flutter dev releases, @pcsosinski).

This part seems problematic as well, will those commits ship with flutter stable? Does that mean the Dart 2.10 that ships ?>with flutter is different from the standalone 2.10 release?

No, these commits can't go to Flutter stable. Flutter stable will always use a stable Dart. We use the same branch-point when we go to beta.

have we bumped to 2.11 yet? if not, why not?

Yes, the bump landed this morning. Dev is on 2.11 now (it seems there is a bug in the roller and it didn't reset the pre-release counter so we're at 2.11.0-153.0.dev which is ugly but shouldn't cause any trouble).

[jakemac53]

No, these commits can't go to Flutter stable. Flutter stable will always use a stable Dart. We use the same branch-point when we go to beta.

👍 - dev releases of flutter may have commits which don't make it into stable though?

[athomas]

They will eventually reach stable, but only with a Dart stable release. For instance, the commit you need will not hit Flutter stable until 2.11 hits Flutter stable.