Any more comments @danquirk or @mhegazy?

👍 assuming that running it yourself proves that it works :)

Is the goal to be able to ship a nightly release of TypeScript without that becoming the default install (i.e. not what you get when you npm install -g typescript), while continuing to ship the stable releases to the same package name as the default installs?

Versions

Currently we use the major.minor.patch of NPM as expected for each release, e.g. we will release 1.5.0, followed by 1.5.1, 1.5.2, 1.6.0, etc... A version may be suffixed by a prerelease version starting with a -, and these are considered to be earlier versions than those without a prerelease part. For example, 1.6.0-dev.1 is considered to be a lower version that 1.6.0.

Parts in the prerelease (separated by dots) field are compared as integers if numbers, or lexically if they contain ASCII letters. For example, 1.6.0-dev.2 is earlier than 1.6.0-dev.10, (however anything that starts with -beta would come before anything starting with -dev due to beta sorting before dev).

Build metadata may also be appended with a leading + sign, however this is ignored for version comparision. It could be useful to datestamp however, e.g. 1.6.0-dev.1+2015.10.29.

I propose a numbering schema as follows:

• Official releases continue as currently, i.e. 1.5.3, 1.5.4, 1.6.0, 2.0.0, etc... with no prerelease or build metadata parts.
• Nightly dev builds for each upcoming release are versioned with a prerelease tag of -dev.<n>, where n is an incrementing integer, i.e. if working toward 1.6.0 we would have nightly builds versioned 1.6.0-dev.1, 1.6.0-dev.2.. 1.6.0-dev-33, etc... Using a simple integer rather than a date allows for multiple releases a day if desired.
• Use the build metadata to timestamp the nightly builds. This isn't used for versioning, but is useful metadata on a release, e.g. 1.6.0-dev.12+2015.9.15. (I'm also OK with not adding this, as it's not particularly attractive to read).
• Optionally ship higher quality prereleases as "beta" releases using the same pattern, i.e. 2.0.0-beta.2+2015.12.25.

Tags

NPM uses a concept of tags to mark a package. For example, by default when you publish a package it will get the latest tag, and when you install a package without specifying a version or tag, you by default get the version with the latest tag.

A common pattern is to tag pre-releases with a next tag, and not latest. Thus anyone simply running npm install <pkg> will not get a prerelease version, as it does not have the latest tag.

I propose the following tagging scheme:

• Any official release gets the default latest tag. Thus anyone installing the default npm install typescript with get the latest official release.
• Any prerelease (including dev and beta builds) gets the next tag. Thus to install the latest prerelease the command would be npm install typescript@next.
• As usual, any specific build can be required using the explicit version, e.g. {"typescript": ">=2.0.0-beta.1"}, regardless of tagging.

Another option is to use a dev and beta tag, rather than next. In this way we have two channels for prereleases, and the install can choose which via either npm install typescript@dev or npm install typescript@beta. Personally I think just having next is fine, and if a specific prerelease is required, then the version should be given (i.e. npm install typescript@2.0.0-beta.2).

Just to summarize action items from @billti comment:

• version to be <current release version>-dev<monotonically increasing number>
• keep the package name the same typescript
• add a tag dev to the package

Thanks @mhegazy , that's pretty close. Don't forget the "." between the -dev and <monotonically increasing number> though, else -dev2 will be considered newer than -dev10 (based on ASCII sort order) 😕

I like angularjs project style. e.g. 1.4.4-build.4120+sha.cce084e
I think that's beneficial that contains the commit hash.

How about using the date in the monotonically increasing number

How about using the date in the monotonically increasing number

I wanted to go with this, @billti mentioned that a date string like 20150720174409141 might be annoying for people, though I think most people will just copy/paste anyway when they want a specific build.

I guess we could put the date/time as parts of the prerelease version, and the commit as part of the build metadata i.e. 1.6.0-dev.20150729.2230+sha1.5e66113. That's a bit of a mouthful, but they are dev builds I guess.

Personally, if we're only going to publish one dev build a day, I'd rather just have the date, and I'm not sure how useful having the commit on the build number is. i.e. just use 1.6.0-dev.20150729. That seems quite readable and practically as useful.

👍

I have had great success with having the patch version (or build version in this case) be the number of git commits since the last tagged release. I wrote a tool for .NET projects that automatically generates a version file on build: https://github.com/Zoltu/Zoltu.Versioning. In theory, someone could write a similar tool for gulp (or whatever your build/deploy tooling is), though it would require a little work.

It is worth noting that you can get the commit count using git describe --match <tag-glob>. For example, if you tag your major releases vX.Y.Z you can do git describe --match "v*.*.*" and that will return something like v1.5.3-32-abcd123. You can then split this string on - and you will have [previousReleaseTag, commitsSinceTag, shortHash]. You can then release with a version like v1.5.3-32, which will be monotonically increasing and reference a specific git commit (assuming you don't rewrite history).

@DanielRosenwasser can you add a quick blurb in what's new, and to the main readme file.