Any software developer and even user nowadays will know the concept of version numbers. They are a way to easily identify and keep track of, well… the version of the application. But why exactly is it important to be able to do this?
In this blog post I limit myself to discussing different types of versioning systems as well as the reason to use one. In the next blog posts I will give my opinion about using such a system from both a developer’ and a user’ perspective respectively.
I started off my professional career programming in Java, which wasn’t my preferred language, but as there is a lot more demand for it there are more jobs available and thus it made sense I ended up programming in it. Nevertheless I have always felt the urge to program using C++ some more, and in my latest job switch I did make the switch from Java to C++, but not all was rainbows and sunshine. It seems that my idea of what C++ was has been distorted over the years and Java has grown on me a lot more then I was aware of.
Every software developer should be familiar with some type of versioning system, be it git, Subversion, Mercurial or some other. The advantages offered by using such a system are plentiful, they are that vast that such a system is often also used for other types of documents, be it in a different format. Services such as Google Docs, OneDrive or Dropbox offer the exact same features because they have recognised that having a history of your documents goes way beyond source files.
So we all acknowledge that keeping your data in a versioning system is a good way, but this opens up a different question. How should you organise your documents? I don’t mean which folder hierarchy, which in itself is already a challenge, but I mean the actual location. It makes sense that you want to keep your files close together, but how do you categorise your documents? Based on topic, type, target audience?
Depending on what type of business you are active in, you either often start new projects from scratch, or not at all. In the first case you are more involved with proto-typing and experimental work whereas in the latter you are working on a product that needs to be supported, upgraded and maintained.
Starting code from scratch has a lot of benifits mostly caused by the freedom that comes with it. You are not bound to any choices made in the past, you are free to choose your own way of working that you are used to and feel comfortable with. There is also no legacy code that you need to understand and may be badly documented.
But what I want to address in this blog post is all the side-setup that is required when setting up a new project, and how important it is. Should it all be done from the start? Or can you delay it until it really becomes important?
I remember my time at the university, when working on C++ code, all of the command line commands I executed to get the my to compile and link. For the small projects I did back then, that was more than enough. We did get some small introduction into make, but we didn’t go into detail about how it all worked. When we started to work with Java, we had to use Maven, and again we didn’t get any real introduction. In my short career I have discovered the world of Maven and I am now more aware of how it all works, making me proficient enough to do what I need to manage bigger projects.
My love for C++ however never really faded, and I have been looking into doing some more C++ coding again. To get me started I was investigating build process tools for C++, in my search I found a couple of solutions: CMake, Maven and Gradle. The goal I set out for all of these tools, was to get a simple project and some tests for it to build.