5

I have to start using versioning for my project which is a web app so compatibility isn't really a problem. I think using a 

Major.minor.revision.build

is too cumbersome. I am almost convinced to do it with just the build number.

I don't care for hotfixes, feature releases, etc. This is a web app. I will never have one big update, it will always be a set of incremental updates. All my "clients" will always use one and only one version of my app which will be under my control on my server. So using that Major.minor.revision.build doesn't make much sense to me.

Is there anything I am missing here?

Improve this question
3
  • 1
    Why have a version number at all? If you are serving a web app and everyone is using the same version, there what point would the version or build number serve? I'd have thought you'd be better off simply tagging git (or whatever source control you are using) with eg, the date and time, prior to each update.
    – David Arno
    Commented Jul 15, 2016 at 12:23
  • I need version numbers to invalidate browser caches on client side.
    – Achshar
    Commented Jul 15, 2016 at 12:31
  • Just use the git commit ID then?
    – Criticizing Israel not allowed
    Commented Sep 27, 2017 at 0:01

2 Answers 2

Reset to default
2

Is there anything I am missing here?

Yes. You are missing the fact that you are human and lack perfect foresight. One day you will find that you did many things that were just plain wrong or that prevent you from making forward progress.

When that happens (and it does happen to almost every software project of sufficient complexity), you will have to break backwards compatibility. You need some mechanism to tell your users that (for example) release #13 provides a number of new features, fixes a huge number of formerly unfixable bugs, but does so at the cost of requiring your users to rewrite some of the software that uses your package.

The build number, which monotonically counts from one (or zero) hand pwards doesn't communicate much. You need something that tells the users of your package how much work they need to do to take advantage of your latest release. At a minimum, I'd recommend you use a major.minor numbering scheme. This may suffice if the project remains small. Note that the build number is absent from this scheme.

If your project has the chance of growing beyond a one person project, you might want to advance to a major.minor.patch numbering scheme. This is the approach taken in semantic versioning. Once again, the build number is absent from this scheme.

Telling your users that they may have to rewrite significant chunks of their software that uses your package (a bump in the major release number) conveys a lot of information. Telling your users that they need to watch for behavior they relied on that was in fact a bug (a bump in the minor release number) also conveys a lot of information. Telling your users that behavior that everyone has avoided up until now because everyone knew that your software used to choked (a bump in the patch number) also conveys a lot of information.

The build number, on the other hand, doesn't convey much information at all.

Improve this answer
6
  • 2
    Your point of not knowing how things will go in future is perfectly valid. But my users are school teachers who log in with user/password and click a bunch of buttons. They don't know and never will know or care about bug fixes, version numbers, etc. But I will heed to your advice of using major.minor. I think I will go with a compromise of major.minor.build. My reason for adding a build at the end is that I need to have a version that constantly changes with even a small change in code. This is needed to invalidate certain important caches on client side.
    – Achshar
    Commented Jul 15, 2016 at 12:39
  • So you requirement is not user related (I want to know which version is hosted), but a software requirement (I want to refresh data). That's unrelated to the build number question.
    – RvdK
    Commented Jul 15, 2016 at 12:58
  • See: stackoverflow.com/questions/29292051/…
    – RvdK
    Commented Jul 15, 2016 at 13:05
  • 3
    This answer makes perfect sense for any publicly consumed library but doesn't help the OP. Build numbers will also handle any unforeseen foresight. The users are not consuming the semantic version in any meaningful way they just use the only version of the application. The users will not be sitting on a release or have to rewrite anything because they haven't written anything against a particular version at all.
    – pllee
    Commented Jul 15, 2016 at 21:06
  • 3
    The OP doesn't indicate at all that anyone is building anything against his web app. This answer only argues from the point of view of software developers consuming a package, which is not the case, and so isn't very compelling.
    – Andy
    Commented Jul 15, 2016 at 21:35
2

It sounds like you are the lone consumer of your application code so you don't need semantic versioning at all. Using build numbers will allow you to change your code as many times as need be without breaking anyone. Also there are build tools that don't even use any semantic input to break the cache they just generate a hash of the file contents and include it in the filename.

Now if you start writing other other spinoffs of your application that rely on common libraries or make some sort of public 3rd party plugin system then yes I would use semantic versioning. If that is needed in the future that can probably be added in trivially.

Improve this answer
2
  • That was actually the train of thought that led me to ask this question. I guess my situation is not as common as I thought it was.
    – Achshar
    Commented Jul 15, 2016 at 21:14
  • @Achshar no it is actually quite a common situation. Tools exists so you don't even need build numbers let alone semantic versioning. Here is a guide on how to do hash based cache busting. medium.com/@okonetchnikov/…
    – pllee
    Commented Jul 15, 2016 at 21:58

Your Answer

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

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