Status of idl-2.0 design docs and visibility into future roadmap.

[crossleydominic]

Over the past six months we've been preparing to rollout Smithy internally in our organization as a way to help us build software. We're just at the point where we're delivering training to our teams, running workshops and about to start putting our first bits of Smithy specified software into production (again, thanks for open-sourcing this, it's been very helpful).

One of the observations we've had whilst delivering internal training and writing documentation is that, in v1 of the IDL, boxing and defaulting behaviour for some simple types is hard to explain and the semantics are a little non-obvious. I was going to raise an issue to discuss this with you when, quite by accident, I discovered this: https://github.com/awslabs/smithy/blob/idl-2.0/designs/default-zero-value.md
This design proposal nicely solves all of the questions I would've raised and, IMO, is a much simpler, easier-to-teach approach than the original boxing design.

Right now, our internal tooling only targets v1 of the IDL but at some point we'll migrate towards v2. To keep this transition simpler for our internal teams we'd like to selectively break with the v1 spec within our tooling such that it smooths our migration path to v2 and removes the difficult to understand boxing behaviour (aside, we've written our own code-generator, rationale/background here: #947 (comment)).

My issue can be summed up in two questions I suppose:

1. Specifically, what is the status of the default-zero-value design document? Is it just a proposal for v2 (and ultimately get rejected possibly) or is it accepted and is fully expected to materialize in v2?
2. Generally, would it be possible to gain more visibility into the upcoming project roadmap? Apologies if it is documented but I couldn't find anything that talks about the idl-2.0 branch in the existing documentation, knowing it exists helps us keep an eye on whats coming up and prepare for work we need to do internally. Perhaps adding a status field to design documents so that external parties know if they are just for discussion or whether they've been accepted for inclusion would also help. Greater visibility into the Smithy roadmap might also help consumers keep abreast of other important changes (e.g. Breaking Change to limit sets to string, blob, byte, short, integer, long, bigInteger, bigDecimal #1106, again, I stumbled across this issue by accident by having great difficulty implementing Sets for exactly the reasons discussed. I also discovered reading the PR that @uniqueItems is also being deprecated. Fortunately our tooling doesn't support that trait yet but our decision whether to implement it at all would've greatly been informed by the knowledge of its deprecation). The above are just a few specific examples that might have been rendered moot with greater visibility into the project roadmap. For sure, I could do better at keeping an eye on the Smithy repo and the goings-on in it, which I'll be doing in the future too.

Many thanks, keep up the great work.

[cmoher]

Thanks for your feedback. We are happy to hear about the use of Smithy in your organization. We have been working hard on Smithy IDL 2.0 for some time now. We're putting the final touches on IDL 2.0 and hope to release it in early May. We will continue to support IDL 1.0 and will offer a migration tool to make the transition to 2.0 as smooth as possible. We're planning to publish a release candidate for IDL 2.0 in the near future, which will include all of its features and a sizeable changelog going over everything that's set for the release.

Specific responses to your questions:

1. Design Acceptance: All of the documents that are in the designs folder on the idl-2.0 branch are accepted and implemented on that branch. Merging of the PR where they're proposed is the indication of their acceptance, discussion (and potential rejection) would happen there or before making a pull request. This should be clarified a bit in our Contributors file.
2. Roadmap: We hear you on this point and we're open to providing more visibility on the roadmap. Finding the right way to do so will take some time. We will discuss this internally and make a post or the changes themselves when we've landed on a solution.

[crossleydominic]

Excellent, thanks for the response, that all makes sense. We can go ahead with our speculative plans and remove boxing from our tooling before rolling it out internally to keep the learning curve/adoption path smoother. Thanks.

[mtdowling]

We shipped IDL 2.0 yesterday. More information can be found in the changelog and blog post: https://aws.amazon.com/blogs/developer/introducing-smithy-idl-2-0/