Re-evaluate the logic used to increment nuspec version

[staxmanade]

The current versioning logic works like this.

if no version is found, starts off with
0.0.1 then
0.0.2...0.0.9 then 0.1.0

Not sure if we should incrementing the minor (and eventually) major numbers - but I guess it'll-do for now.

Feels like we could potentially increment the build forever? - 0.0.1...0.0.2445?

[Igorbek]

I think should be the way to provide base version of packages. That because typings must be consistent with libraries created for. Each js library have its own version, and user must know what version of library provided by the typing.

I think only the build number (4th part of version) should be incremented forever.
And the first 3 parts of version reserve for library-specific version.
Also need to support version suffixes like 'beta', 'pre' etc.

Examples (x - build number):
1.0.1 -> 1.0.1.x
0.1-alpha -> 0.1.x-alpha or 0.1.0.x-alpha (need to think :) )

The way to provide this information might be some file with metadata inside typing folder with such information:

• base version (up to 3 numbers with optional suffix)
• description
• tags
• authors
• may be something more

[Bartvds]

I totally agree that we should get some more info into DT, for re-use by toolings:

Note 1: There is some overlap here with some earlier discussions (on DefinitelyTyped issues and TypeScript's forum).

Note 2: I've worked with @Diullei on TSD and recently adopted and am rebuilding the project as DT git-api client and would like to use these meta data too.

Some input for the discussion (already spend much thought on related issues :)

1. A definition file can be for multiple library versions: ideally it should work per semver major+minor but I'm not sure if the data is clean enough.
2. Many definitions have (limited) meta-data comment in their header (example). I have made some attempts at parsing this: with some brutal RegExp's it's doable to extract all fields (if we sweep to clean the missing ones).
3. There were some community requests to have a look-up for aliases that map module names to definition files: for example angular-browserify -> angularjs/angular.d.ts.
4. There were some related requests to use this map to have a master list of (aliased) 'single' names as used in package.json, bower.json (et al) and map them to the folder+file.d.ts files. this can then be used in tools, like to auto-install definitions.
5. Some definition files (used-to) have semver postfixes. For TSD I was thinking to parse these from the names an use them for querying, see for example the node.js defintions. I like this pattern as is it very physical. Might minimise it to just MAJOR+MINOR and drop PATCH+ BUILD.
6. There was some community interest in annotating which JS package managers have the module for a given definitions. (nuget/npm/bower/component.io etc)

Keep in mind that the data is slightly dirty: users make mistakes and there is an endless stream of small fixes on every version.

This issue also touches other growth-issues like these: DefinitelyTyped/DefinitelyTyped#428