RFC: @version tag

Customer often need to know the versions of particular classes, methods, and properties so they can target specific releases. While this information can be passed through the description, it would be beneficial for downstream tooling to avoid parsing extra text.

My request would be to let this field be an arbitrary string. So @version 1.1 and @version Excel API 1.4 both work.

[PissedCapslock]

For the first version of TSDoc, can’t we leave out the added/deprecated/removed use-case and just stick to @since or @version ?

To me, it feels like adding support for indicating when a method was deprecated or removed is another use case, which might warrant their own tags (and which can be added later), e.g.

@since 1.0
@deprecated 3.5
@removed 5.0

[sharwell]

I find @version to be a bit ambiguous. I would consider using @since instead, as it clarifies that this is the version where the API is introduced (or stabilized), and another tag could be used where applicable for the version where the API is deprecated.