Alex Jerabek

How would this affect overloads with differently documented parameters? Here's a common example from our d.ts: ``` load(option?: Excel.Interfaces.StyleCollectionLoadOptions & Excel.Interfaces.CollectionLoadOptions): Excel.StyleCollection; load(option?: string | string[]): Excel.StyleCollection; load(option?: OfficeExtension.LoadOption): Excel.StyleCollection;...

Am I correct in thinking `@partOf` wouldn't help the Intellisense experience? Would the user see the `partOf` text or the "main" function's description?

Just to be clear, individual parameters on overloads would not be explicitly documented with `@param` tags, correct? We'd have to fully contain all that data in the base function's description....

I would think `@version` would be the same level of importance as `@beta` and `@remarks`. It's important information for an evergreen d.ts file.

I can't think of a scenario where you'd need a multi-line version. I'll trust your judgement on the tag category. Multiple version tags would be interesting, but probably too complicated...

@pgonzal Is it better to have the familiarity with `@version`, despite the block tag problems? Or is it okay to add a new, albeit less error-prone term? My vote would...

@Rick-Kirkham It could go anywhere after the initial description. You could have ```TypeScript /** * The Widget class. * @remarks * Details... * @version 1.2 */ export class Widget3 {...

@sharwell Hmm, I didn't consider the need to convey a range of versions. Would something like `@addedInVersion` be more descriptive? That's akin to how Android docs describe things in [their...

@sharwell Thanks for sharing that jQuery link. It makes an argument for an introduced and depreciated tag (I'm guessing in a d.ts file, you'd just remove the API in question...

I'm down for option 2, since it mirrors reality the closest.