AIP 2: AIP Numbering

[rhamiltonsf]

See Google's AIP 2

[dret]

i am not sure what this issue is about. iff it is about my why/what/how proposal: this is different. this is the way how the AIP numbering space is organized. that's important and seems well-done. but the question i was discussion was how to write individual AIP, and for those with specific guidance (i.e., no process AIPs like AIP 2), it might be interesting to provide a general structure that makes it easier to understand why guidance exists, what can be done to address the issue, and how to do this for a specific style/tech. for example, for versioning you can say:

• why: consistent versioning makes sense to create a more predictable API consumer experience.
• what(1): one way to go is to never change APIs. this is the salesforce way and works, but of course it has quite a bit of operational consequences.
• what(2): if you're versioning then semver makes sense because it forces you to think about breaking and non-breaking changes.

[rhamiltonsf]

@dret, this is just a placeholder to track as a group that we want to de-Google AIP 2 in preparation for releasing a set of common AIPs.

The style you are talking about is a larger discussion we should have to evaluate the format of each individual AIP, methinks.