Document preview2 vs future features

[lann]

There are a number of features that are currently specified in this repo which will not make it into the preview2 implementations. @lukewagner's suggestion is to cut a preview2 branch from this repo and remove the specifications of those features from that branch.

Starting a list of features that are expected to not be in preview2 implementations:

• [ ] value imports
• [ ] interface subtyping
• [ ] component start functions (?)

[lukewagner]

Yep, sounds good to me. I'll get to this in a bit if noone beats me to it.

[alexcrichton]

One thing I'd suggest is to perhaps do the opposite and have a next branch instead of a preview2 branch because the state of preview2 is probably what many newcomers are going to be interested in viewing for a good amount of time and having the right docs by default I think is important (as opposed to a README disclaimer saying "go here for non-future-facing docs")

Otherwise though for what to not be in preview2 on the topic of subtyping specifically I'd propose that we should remove all value-level subtyping, but prefer instance-level subtyping. In other words communication with value types (or interface types) must all exactly match: struct fields in the same order, exact same primitives, exact same variant orderings, etc. I don't believe we have a strong use case for having subtyping at this time at this layer given all the work done on WIT and making it easy to have dependencies, meaning that everyone is likely using the same source of truth. Iteration of APIs over time I think is the next major motivation for subtyping but I think we've still got a good deal of work to do on that so I personally feel it's best for the "next" time-frame.

For instance-level subtyping I think that's important to have which is along the lines of "you asked for 2 functions and I gave you 3 and that's ok". In other words it's ok to drop entire functions or entire types at the instance (or component level) as appropriate. That's relied on and used in tooling today and AFAIK all works well.

[ricochet]

If we know an issue is something we'd bucket in the next milestone, then we should add it to the Preview 3 milestone. This will help plan the next release regardless of the chosen branching strategy.

For changes that are nice-to-have but not immediately required for key implementations, I recommend we judiciously label enhancement.

+1 for the next branch approach. If we go this route, we should start with rc tags for 0.2.0 until we're ready for the rubber stamp of 0.2.0.

[alexcrichton]

This was discussed at today's component model sync meeting, and the conclusion there was to take a relatively lightweight approach to this for now which can optionally evolve into more process later on. The action items are:

• Current items in the spec not implemented or part of preview2 will be demarcated with a emoji that is TBD.
• New features added to the spec will have their own emoji and be demarcated with this emoji.

The thinking is that we can still keep all discussion/spec/etc details all here for now as we probably don't warrant multiple repositories just yet and there's still a lot of cross-cutting discussions and such. That being said there can be a clear marker of "this is not in preview2" or similar where whenever an emoji is seen it's an indicator to correlate the spec with the meaning of the marker.

So in that sense no branches, only main, but with 100% more emoji.