[Proposal] Change Flutter's versioning scheme

[itsjustkevin]

Use case

Flutter's current versioning scheme considers the dev channel which has been recently deprecated. There is an opportunity to rethink Flutter's versioning scheme to align it with a version scheme similar to Dart's or more traditional semantic versioning.

Currently Flutter's stable version increments on a monthly basis, for example, Flutter 2.8 was released in December, while Flutter 2.10 will be released in February with no Flutter 2.9 release in existence.

Proposal

I propose that Flutter move towards a Major.Minor.Patch versioning scheme.

1. Major: Any change that causes API incompatible breaking changes. Flutter 2 -> Flutter 3.
2. Minor: Any incremental updates or feature additions.
3. Patch: Any bug fixes, where Flutter would traditionally label these changes as hotfixes.

For beta releases the version could look similar to, 2.10.1.beta-1.

Considerations

Timing

If this change were to be considered, what would be the proper timing for this?

1. Immediate
2. Upon the release of Flutter 3

Dependancies

1. Would this change affect any tooling or packages written by the community that rely on the current versioning schema?
2. Has anything been affected by the removal of the dev channel?

[mit-mit]

I'd recommend aligning the with versioning scheme Dart uses: https://dart.dev/get-dart#release-channels

[stuartmorgan]

1. Major: Any change that causes breaking changes. Flutter 2 -> Flutter 3.

Would that only be enforced at stable-channel granularity? If not, we would almost certainly have multiple major version bumps between each stable release.

(If so, it's not clear that we'd ever actually use the minor version field, because it would only come into play if we went three months on without any breaking changes.)

[itsjustkevin]

@stuartmorgan I will update the original to specify that Major changes only include API incompatible changes such as the sound null safety change. Minor changes would be things like adding Windows accessibility support.

[stuartmorgan]

I assumed that's what you meant by breaking changes. My point was that I see two main options here:

• semver applies to every release on every channel, including master: This means we'd have to apply it on a per-PR level. If we do that, we are likely to bump the major version multiple times per stable release, so that for most users (those on stable) we'd go from, say, Flutter 2 to Flutter 5, since each individual breaking change on master would bump the major version.
• semver only applies to the stable channel: In this case, I would expect that we would probably always bump the major version (have we ever actually had a full stable release with no breaking changes?). And if that's true, we'd never use the minor version because the major version would be updated, the minor version would reset to zero. Cherry-picks to stable are always bug-fixes AFAICT, so would only affect the patch version, not the minor version.

[stuartmorgan]

It's also worth noting that our breaking change policy doesn't actually follow semver; API-breaking changes that don't break customer tests should be breaking per semver, but are not according to our current policy.

[Hixie]

Null safety was actually not backwards incompatible (due to heroic efforts from the language team).

What is your definition of "breaking change"? The definition in our current breaking change policy would imply that we'd be making major revision bumps multiple times a week, but that definition is rather loose and considers many things that are technically breaking to be totally fine, as @stuartmorgan says. A strict definition would consider potentially every single change to be a breaking change (after all, someone could depend on the git hash of the commit). A looser definition than what we have now seems too loose to be useful.

FWIW, the current scheme changes the major version number when @timsneath wants to change it, which IMHO is probably the most practical definition. I don't have a strong opinion about the minor and patch numbers, but our versioning scheme should be detailed enough to allow any commit to master to be versioned (today we do this by counting commits and appending .pre.WW versions; this is done automatically by the tool and seems to work ok). Our current scheme also has an extra bit (-1.0) that to be honest I don't fully understand and would be fine with dropping. :-)

[XilaiZhang]

from triage: is there a decision on this?

[itsjustkevin]

Closing as there is no alignment, will revisit later.

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.