On 15.11.2013. 11:01, Jacob Carlborg wrote: > On 2013-11-15 10:16, luka8088 wrote: > >> Yes. For example, if you have version 0.1, 0.2 and 0.3. And you find and >> fix a bug in 0.3 but you still wish to support backport for 0.2 and 0.1 >> that you indeed need to make 3 releases. 0.1.1, 0.2.1 and 0.3.1. > > There's a difference in still supporting old releases and working on > five different releases at the same time that hasn't been released at all.
Yeah. I agree. Bad idea. > >> But then again having LTS that others have mentioned seems better. So >> that only each nth release has 2.x.1, 2.x.2, 2.x.3. >> >> From my perspective, not separating releases with improvements + bug >> fixes from releases with only bug fixes is an issue. Because every new >> improvement implies risk of new bugs and some users just want to have >> one version that is as stable as possible. >> >> What do you all think about http://semver.org/ ? >> We use this king of versioning notation at work and it turns out to be >> very good. > > I like it but I'm not sure who it's applied to applications. It's clear > to see how it works for libraries but not for applications. I mean, what > is considered an API change for an application? Changing the command > line flags? > I think API change could be analog to features change (and the way they are interfaced). So the version consists of x.y.z z increments only on bug fixes. y increments when new features are added, but they are backwards compatable. Incrementing y resets z to 0. x increments when backwards incompatible change are made. Incrementing x resets y and z to 0.
