Start annotating which version of the spec added a thing (#3425)

* Introduce a new "added-in" template and use it on endpoints

* Use "added-in" on schema properties too

* Annotate sections of the spec with their added versions

* Demo of "added-in" on a room version (to be fleshed out)

* Use clearer versioning semantics

* Update and fix validator for Swagger custom properties

* Fix docs

content/client-server-api/_index.md

@@ -1039,9 +1039,9 @@ This returns an HTML and JavaScript page which can perform the entire
 login process. The page will attempt to call the JavaScript function
 `window.onLogin` when login has been successfully completed.
 
-Non-credential parameters valid for the `/login` endpoint can be
-provided as query string parameters here. These are to be forwarded to
-the login endpoint during the login process. For example:
+{{% added-in v="1.1" %}} Non-credential parameters valid for the `/login`
+endpoint can be provided as query string parameters here. These are to be
+forwarded to the login endpoint during the login process. For example:
 
     GET /_matrix/static/client/login/?device_id=GHTYAJCE
 
@@ -1746,6 +1746,8 @@ The allowable state transitions of membership are:
 
 ##### Knocking on rooms
 
+{{% added-in v="1.1" %}}
+
 <!--
 This section is here because it's most similar to being invited/joining a
 room, though has added complexity which needs to be explained. Otherwise

content/client-server-api/modules/end_to_end_encryption.md

@@ -992,6 +992,8 @@ user-signing keys.
 
 ##### QR codes
 
+{{% added-in v="1.1" %}}
+
 Verifying by QR codes provides a quick way to verify when one of the parties
 has a device capable of scanning a QR code. The QR code encodes both parties'
 master signing keys as well as a random shared secret that is used to allow

content/client-server-api/modules/guest_access.md

@@ -44,7 +44,7 @@ for retrieving events:
 -   [GET /rooms/:room\_id/event/:event\_id](#get_matrixclientv3roomsroomideventeventid)
 -   [GET /rooms/:room\_id/state/:event\_type/:state\_key](#get_matrixclientv3roomsroomidstateeventtypestatekey)
 -   [GET /rooms/:room\_id/messages](#get_matrixclientv3roomsroomidmessages)
--   [GET /rooms/:room\_id/members](#get_matrixclientv3roomsroomidmembers)
+-   {{% added-in v="1.1" %}} [GET /rooms/:room\_id/members](#get_matrixclientv3roomsroomidmembers)
 -   [GET /rooms/:room\_id/initialSync](#get_matrixclientv3roomsroomidinitialsync)
 -   [GET /sync](#get_matrixclientv3sync)
 -   [GET /events](#get_matrixclientv3events) as used for room previews.

content/client-server-api/modules/instant_messaging.md

@@ -15,7 +15,7 @@ room itself such as a room name and topic.
 
 {{% event event="m.room.message.feedback" %}}
 
-Usage of this event is discouraged for several reasons:  
+Usage of this event is discouraged for several reasons:
 -   The number of feedback events will grow very quickly with the number
     of users in the room. This event provides no way to "batch"
     feedback, unlike the [receipts module](#receipts).
@@ -62,25 +62,25 @@ listed for the tags below. Where `data-mx-bg-color` and `data-mx-color`
 are listed, clients should translate the value (a 6-character hex color
 code) to the appropriate CSS/attributes for the tag.
 
-`font`  
+`font`
 `data-mx-bg-color`, `data-mx-color`, `color`
 
-`span`  
-`data-mx-bg-color`, `data-mx-color`, `data-mx-spoiler` (see 
+`span`
+`data-mx-bg-color`, `data-mx-color`, `data-mx-spoiler` (see
 [spoiler messages](#spoiler-messages))
 
-`a`  
+`a`
 `name`, `target`, `href` (provided the value is not relative and has a
 scheme matching one of: `https`, `http`, `ftp`, `mailto`, `magnet`)
 
-`img`  
+`img`
 `width`, `height`, `alt`, `title`, `src` (provided it is a [Matrix
 Content (MXC) URI](#matrix-content-mxc-uris))
 
-`ol`  
+`ol`
 `start`
 
-`code`  
+`code`
 `class` (only classes which start with `language-` for syntax
 highlighting)
 
@@ -464,14 +464,16 @@ text should be `"sent a video."`. For `m.audio`, the text should be
 
 ##### Spoiler messages
 
-Parts of a message can be hidden visually from the user through use of spoilers. 
-This does not affect the server's representation of the event content - it 
-is simply a visual cue to the user that the message may reveal important 
+{{% added-in v="1.1" %}}
+
+Parts of a message can be hidden visually from the user through use of spoilers.
+This does not affect the server's representation of the event content - it
+is simply a visual cue to the user that the message may reveal important
 information about something, spoiling any relevant surprise.
 
-To send spoilers clients MUST use the `formatted_body` and therefore the 
+To send spoilers clients MUST use the `formatted_body` and therefore the
 `org.matrix.custom.html` format, described above. This makes spoilers valid on
-any `msgtype` which can support this format appropriately. 
+any `msgtype` which can support this format appropriately.
 
 Spoilers themselves are contained with `span` tags, with the reason (optionally)
 being in the `data-mx-spoiler` attribute. Spoilers without a reason must at least

content/client-server-api/modules/secrets.md

@@ -5,6 +5,8 @@ weight: 110
 
 ### Secrets
 
+{{% added-in v="1.1" %}}
+
 Clients may have secret information that they wish to be made available
 to other authorised clients, but that the server should not be able to
 see, so the information must be encrypted as it passes through the

content/rooms/v7.md

@@ -26,7 +26,7 @@ Room version 7 adds new authorization rules for events to support knocking.
 [Room version 6](/rooms/v6) has details of other authorization rule changes,
 as do the versions v6 is based upon.
 
-For checks perfomed upon `m.room.member` events, the following conditions
+{{% added-in this=true %}} For checks perfomed upon `m.room.member` events, the following conditions
 are added in context:
 
     If type is `m.room.member`: