I found that the following code fragment worked best for me. Since it uses require to load the package.json, it works regardless of the current working directory. var pjson = require(‘./package.json’); console.log(pjson.version); A warning, courtesy of @Pathogen: Doing this with Browserify has security implications. Be careful not to expose your package.json to the client, as … Read more
We use Team Foundation Server Team Build and have added a block to the TFSBuild.proj’s AfterCompile target to trigger the ClickOnce publish with our preferred version number: <MSBuild Projects=”$(SolutionRoot)\MyProject\Myproject.csproj” Properties=”PublishDir=$(OutDir)\myProjectPublish\; ApplicationVersion=$(PublishApplicationVersion); Configuration=$(Configuration);Platform=$(Platform)” Targets=”Publish” /> The PublishApplicationVersion variable is generated by a custom MSBuild task to use the TFS Changeset number, but you could use your … Read more
Here’s a grep command to do that: grep “version\”\:” bower_components/thepackagename/.bower.json Also, a command to see versions of all bower components for the project – this list can be a handy CI artefact: grep “version\”\:” bower_components/*/.bower.json
As of Nuget 2.8 you can add the following attribute to your nuget.config <configuration> <config> <add key=”dependencyversion” value=”Highest” /> </config> </configuration> When resolving your packages, the latest version of that package will be resolved. Other attributes include HighestMinor, HighestPatch and lowest (based on semantic versioning) Source: http://docs.nuget.org/docs/release-notes/nuget-2.8
Instead of adding version in every route you can add it in app level. So It won’t be tightly coupled with API route. import * as express from ‘express’; // v1/get-ride.js const router = express.Router(); router.post(‘/rides/:id’, dep.verifyToken(), (req, res) => { // Your code }); app.use(‘/v1’, router); // v2/get-ride.js const router = express.Router(); router.post(‘/rides/:id’, dep.verifyToken(), … Read more
I would recommend the Semantic Versioning standard, which the Maven versioning system also appears to follow. Please check out, http://semver.org/ In short it is <major>.<minor>.<patch><anything_else>, and you can add additional rules to the anything else part as seems fit to you. eg. -<qualifier>-<build_number>.
Can’t give you the ultimate answer, but consider these 2 points: The feature is of little use to the mainstream user (98% of all users?), so why implementing it, if nobody uses it. Storage space was expensive in the past, so why wasting it on a feature that almost nobody will use?
You need to use a dependentAssembly with bindingRedirect but also you need put dlls in different folder or save with a different name. With this done, you need to put the following in your app.config: <assemblyBinding xmlns=”urn:schemas-microsoft-com:asm.v1″> <dependentAssembly> <assemblyIdentity name=”myAssembly” publicKeyToken=”here token dll” culture=”neutral” /> <bindingRedirect oldVersion=”0.0.0.0-1.0.0.0″ newVersion=”1.0.0.0″ /> <bindingRedirect oldVersion=”1.0.0.1-2.0.0.0″ newVersion=”2.0.0.0″ /> <codeBase version=”1.0.0.0″ … Read more
I would recommend using tags (tag tutorial) From your master branch since you are done v1.0 add a tag called v1.0. git tag -a v1.0 -m “Tagging release 1.0” This way you can always come back to a specific version at any time by calling git checkout [tag_name] Another common practice is to use branches … Read more
I found the answer originally here. I’m repeating the details for ease of reference. There are three ‘versions’ that can be included in the AssemblyInfo.cs file: [assembly: AssemblyVersion(“1.1.1.1”)] [assembly: AssemblyInformationalVersion(“2.2.2.2”)] [assembly: AssemblyFileVersion(“3.3.3.3”)] AssemblyInformationalVersion defaults to AssemblyFileVersion if it is not specified. Likewise, AssemblyInformationalVersion and AssemblyFileVersion default to AssemblyVersion if both are not specified. In your … Read more