versioning

I have been struggling with versioning software for a while now. I'm not talking about a naming convention, I'm talking about how to actually apply a version in a build system all the way through to a release. I generally use major.minor.maintenance-[release type] i.e. 1.0.2-rc1 The problem is managing the version number. I've tried many ways (sticking it in a build file, a properties file, a database, etc,etc) but I haven't found anything that really works well. The closest thing I came up with is using Jira which I documented here: http://blog.sysbliss.com/uncategorized/release-management

I read a lot about versioning REST APIs, f.e. in this thread: Best practices for API versioning? Because of that I would like to use the HTTP-Accept-Header to indicate which version the client is asking for. But how can I apply this in my application? Which changes had therefore be made? How does the marshaller know, which version should be used? Do I have to register my type? What I know is that I have to change the content of the @Produces -Annotation @GET @Path("/locations") @Produces("application/vnd.mycompany-v1+xml") Location[] getLocations(); But what else has to be changed? You can use

From Semantic Versioning : Patch version Z (x.y.Z | x > 0) MUST be incremented if only backwards compatible bug fixes are introduced. A bug fix is defined as an internal change that fixes incorrect behavior. Suppose I have a program at version 0.1.12 . If I had to increment Y ( 0.Y.12 ), should I return Z (0.2.Z) to 0 (becoming 0.2.0 ) or just keep it unaltered (becoming 0.2.12 )? Sam Bloomberg Yes. All numbers should be reset when their parent version is changed. The specification ( http://semver.org/ ) states: Patch version MUST be reset to 0 when minor version is incremented. 来源： https:/

I am interested to know what strategies people have to keep their code AND work versioned across multiple machines. For example I have a desktop PC running XP, a macbook running OSX and VMWare running XP as well as a sales laptop for running product demos. I want to know how I can always have these in sync. Subversion is a possibility for this but i find it less useful for dealing with binary files - maybe I have overlooked something here. What do other people use as they must have similar issues? Do they keep all files on a USB drive and never on the local file system. I am not always online

Is there a simple way of obtaining the application version information from the resource file at runtime? Effectively what I'd like to do is be able to have a "Version X.Y.Z" displayed at runtime without having a separate variable somewhere that I'd have to keep in sync with my ProductVersion and FileVersion. To clarify: yes this is a standard C++ Windows project. I am aware of the GetFileVersionInfo method but it seems silly to have to open the binary from within the version in memory just to query the version information - I'm sure I'm missing something obvious here :-) If the OS is Windows,

I understand that interfaces are contracts and any changes (even additions) break any dependent code. However, I could have sworn I read something a while back that one of the recent .NET versions (3, 3.5??) added a new attribute that could be applied to new interface members. This attribute allowed versioning and/or making members optional. It would have been something like: interface ITest { void MethodOne(); [InterfaceVersion(2)] void MethodTwo(); } I have looked high and low for this but just can't seem to find it. I am wondering whether I simply misunderstood whatever I think I read and

On Windows I'd simply add an RC file with the right data. Do I need to assemble a bundle as usual with an info.plist/version.plist or is there a better, standard , way of doing things? This is for Snow Leopard and later if that is relevant. Thx++ JWWalker It is possible to embed an Info.plist file in an executable as a special Mach-o section. See for example this question . If you have a command line application, then it's just a single file and not a traditional OSX app package (with a Contents folder and a MacOS + Resources folder underneath). If you're not willing to do a full blown