I like this proposal very much and think it will be a great addition to the ecosystem. But I was going to propose a modification similar to @anandabits
Specifically, I'm concerned about the proliferation and interweaving of arbitrary release numbers from the proposed scheme. We might have 0.134 that drops item X on schedule, 0.135 that adds item Y, and then 0.136 dropping Z. A user of the package has to keep track mentally of what they have access to at any given moment.
As an alternative, what about coalescing removal? Something along these lines:
- As in the proposal, changes may be added freely to SwiftPreview, each with a minor version bump
- As in the proposal, they may be added to the stdlib when ready/as time allows
BUT when a new release of the stdlib is made (yearly, I suppose, with Apple's release cycle):
- All preview items that have moved to the stdlib are dropped from SwiftPreview at that time, AND
- The major version of SwiftPreview is incremented
This provides us with a clear and easily describable progression for SwiftPreview: "Oh, yeah,
FrobozzMagicSequence was moved to stdlib in v2, you need to update".