Tag Info

New answers tagged

0

Instead of using a magic number (variable) that is not "present" while viewing code I suggest another approach: Do the versioning with directories, e.g. /the_project/1.0/src/files /the_project/1.1/src/files /the_project/2.0/src/files /the_project/2.1/src/files This way when people are navigating the code they should have little doubt about which version ...


0

Multiple approaches are available for this, mostly convention and politics than technical actually. If you can take research what is done for large open source projects you may find lots of good inspiration. An example of what I 've done for a project I worked for. Versions marked Major.Minor.Patch.Build. build was generated by the build system so ...


2

I develop in a heavily embedded environment, so I'll add in another option: Our devices have a query command to grab the firmware version, and will return the result with a 2-byte number on success. The problem with the above responses is that it may be impractical to add tags like "pre" when you're limited on your data output format. What we've decided to ...


2

Here is a simple way to do it. Since it must be a higher version then the current, the minimal required increment is a minor version. Use that to start with. If later the decision is made to change it to a new major version change it again. Why make it more complex?


0

I used to work on a project where the version was incremented after every added feature. We used semantic versioning so after each change we could increment the version according to whether it was a bugfix, a compatible or an incompatible change. The release version was the version we arrived at after all changes that got into this release. This meant that ...


3

One standard answer to this is in the Maven world. Development versions use the next version number with the suffix "-SNAPSHOT". After a release of 1.0.2, for example, Maven automatically increments the version to 1.0.3-SNAPSHOT.


4

You use your build setup to populate the var. Most build engines allow a search-replace pass of a file and compile in the resulting file. So the actual line in the repo would be var version = @VERSION@; And then through the builder's config settings @VERSION@ would be replaced with the actual version when building (possibly adding debug postfixes and ...


0

It depends on your application. For example, I have a product that comprises a server installation which is several services, and a client application. We package these as 2 pieces - whilst each of the server side components could be installed individually, nobody ever does (or will) so it makes sense to install them as a single item. This allows us to ...


1

One big advantage of option 1 is that as soon as your software passes all the unit tests and acceptance tests against the new set of requirements, you can ship it. If you delay incrementing the version number, then you will have to do another build with the correct version you want to ship. Having re-built it all, you really should re-do all the tests ...


6

If your issue is that the customer might think 1.1.2475.54387 means "something has changed after 1.1" - forget it. In my experience, virtually all customers either don't care what the lower-order components in a version mean, or they do care and understand that they are build numbers and VC revisions, which by definition can never be 0. Slightly more ...



Top 50 recent answers are included