4

I've really big problems with versioning my apps. I'm trying to follow SemVer methodology (I'm not sure if it's a methodology or just set of rules).

I've draw a roadmap for my app's versions.

1.0.1

  • BUG 1 fix

1.1.0

  • FEATURE 1
  • FEATURE 2

1.2.0

  • FEATURE 3

My apps version is 1.0.1 recently (because I've fixed BUG 1). After that development of FEATURE 1 finished. While I work with FEATURE 2, FEATURE 3 is finished. Now what should I do? What's I'm doing wrong?

In shortly, if FEATURE 3 finishes before FEATURE 2, what will be my app's version according to SemVer?

Improve this question
1
  • 2
    The core idea behind semantic versioning is that major version increments signal a breaking change. By following this convention, your users will know whether or not you're breaking backwards compatibility.
    – Robert Harvey
    May 17, 2016 at 14:59

2 Answers 2

Reset to default
12

First of all, SemVer.org is all about version numbering for libraries and APIs. You can borrow the ideas to use for applications, but note that it's not a perfect fit (for example, SemVer says the MAJOR version number increments when you make a non-backwards compatible API change)

You don't work on "FEATURE 2" or "FEATURE 3", you work on "FEATURE {featurename}".

Say you're working on Features A, B, and C. You're at version 1.1.0. If you release features A and C together, you just moved to version 1.2.0. When you release B (even though you started it first), you go to 1.3.0.

Version numbers are for your users so they can track releases.

What if you started a big feature but abandoned it before release. Would you really skip a number in your versioning? (Never! it would confuse the users)

Improve this answer
4
  • First of all, thank you your answer. I just give that feature names (FEATURE 1,2,3) randomly to ask here, normally I'm using meaningful names :) So, roadmap is not strict and can change during development, right? Are you preparing roadmaps like me, while developing apps?
    – Eray
    May 17, 2016 at 15:02
  • Someone should tell Microsoft that. Windows 9 anyone?
    – RubberDuck
    May 17, 2016 at 16:02
  • 1
    @RubberDuck Microsoft didn't skip Windows 9, they just released it a couple decades early. Twice.
    – 8bittree
    May 17, 2016 at 16:45
  • @Eray Roadmaps absolutely can change (though if it's part of a legally binding contract, that change may be difficult). Refusing to update roadmaps to reflect new information is a good way to fail.
    – 8bittree
    May 17, 2016 at 17:31
4

Semantic versioning is quiet on roadmaps: it only cares about the actual release tagged. In your case, if feature 3 is completed ahead of schedule, it's up to you to decide whether it'll make it into 1.1.0 or if it should remain in 1.2.0.

To have that type of flexibility though, you'll want to carefully consider your integration/release process. If you're just merging everything into your release branch/master whenever a feature is done, you won't be able to "hold back" a feature for a future release.

One way to do this is to have release branches. Once you start preparing for the next release, you'd create a branch off of master or trunk that's solely for that release. Only features on the roadmap for that release get merged into that branch. You could have multiple, simultaneous releases being worked on at the same time using this method, with each future release getting its own branch.

With a process like that in place, nothing happens with respect to your versioning when feature 3 is complete: it gets added to the 1.2.0 branch and stays there until you're ready to release 1.2.0.

However, this type of release process can get complicated quickly, and is sometimes prone to error: if a feature is completed but not part of an existing release, where does it go? Should you commit features to both a release branch and a main integration branch? Why was feature 3 promised later if it was going to be worked on first?

Because of this, it's common to take amore agile approach and avoid locking features to specific releases: whenever a feature is ready, it goes into the next release, whatever that is. In your case, you could either:

  • tag a new release after feature 3 is done, which would mean 1.1.0 would have feature 3 but not feature 2, and 1.2.0 would have both features
  • wait to tag a new release until feature 2 is done, which would mean 1.1.0 would have both features
Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.