flutter/docs/ecosystem/Package-migration-to-1.0.0.md
Kate Lovett 49bc6bd54f
[wiki migration] Ecosystem team pages (#148589)
This puts the wiki pages owned by the Ecosystem team into the docs/ecosystem directory as planned in [flutter.dev/go/migrate-flutter-wiki-spreadsheet](https://docs.google.com/spreadsheets/d/1x65189ZBdNiLRygpUYoU08pwvXD4M-Z157c6pm8deGI/edit?usp=sharing) 

It also adds the ecosystem team labels to the label bot for future PRs.

Changes to the content were only updating cross links. The remaining wiki links will be updated after the rest of the pages are relocated, the original wiki links still work in the meantime.

Part of https://github.com/flutter/flutter/issues/145009
2024-05-20 17:44:39 +00:00

1.7 KiB
Raw Blame History

TL;DR To facilitate a smooth ecosystem migration, a package author may ask dependent packages to migrate to a 1.0.0 version with a >=0.x.y+z <2.0.0 constraint rather than a ^1.0.0.

API stability* is an important milestone in a packages lifetime and bumping the version to 1.0.0 is an exciting way to celebrate this moment.

This is what the Semantic Versioning Specification (2.0.0) is saying about pre 1.0.0 versions:

Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

Pub on the other hand treats pre 1.0.0 versions semantically (see pub_semver corner cases), shifting the numbers by one position.

Often, at the time a package author is ready to announce API stability their package is versioned 0.x.y+z. Bumping a package version from 0.x.y+z to 1.0.0 is a major version bump in the Dart ecosystem. Migrations across a major version bump are slower, and may result in some period of ecosystem fragmentation (when some dependent packages are only willing to take ^0.x.y+z and some require ^1.0.0).

To go through an ecosystem migration to 1.0.0 in a smoother way, users of the newly API-stable package (particularly dependent packages) are encouraged to update their constraints to >=0.a.b+c <2.0.0 instead of ^1.0.0, this reduces friction during the transition period while some dependents have updated to post 1.0.0 and some have not.

* While an API can never be guaranteed to be stable, version 1.0.0 is the milestone in which the package author is feeling comfortable to let others depend on the current API, and does not have concrete plans to change it in a breaking way.