We’re going to continue our last blog post about Versions & Releases in Open Source Projects In this case, we’ll be reviewing other terms that can help us to understand the world of versioning and releases. 

When we talk about the stable version of a software product, we’re referring to that kind of version we can use for sure, it’s a version that is already broadly tested and ready for mass usage. At least these kinds of versions surpass the testing stage and the creators of the software refer to this new stage as stable. So, the good practice here is to always use the last stable version. Or at least try to do it. We'll be talking about the upgrading process later. 

When we talk about a deprecated version of a given software that means that the version itself is not receiving any support by the creators, collaborators, community or maintainers. And why does this matter? It's simple: because that version can introduce bugs or security vulnerabilities given the lack of maintenance. So, the good practice here is to upgrade to a newer version that is actually supported by the community. You always can see the last version on the software documentation. 

When we’re developing software, and we achieve a certain amount of months or years working in that fancy project or company, inevitably the code gets outdated. If we started to work on that project 2 years ago, now it's probably that new versions will see the light in that given software. 

The good practice here is always to be up to date. Obviously, sometimes our boss or our customers prefer to create new features instead of upgrading the versions of the project, but it is essential to keep the good practices and avoid security vulnerabilities, and be up to date with the software we use. This doesn't mean that each week or month we have to upgrade the whole project. But at least we need to check for new versions each 6 months as a minimum requirement and a maximum of 1 year. 

If you wait for more than 1 year to check for new versions, your project probably will fall in the legacy category. As you may know, software advance at a speed of light, and we need to always try to be up to date

And it is easy for us now to understand why this is important. We saw in the last blog post about semversion, the concept of MAJOR.MINOR.PATCH and probably doesn’t have any sense to upgrade from Rails 5.1.0 to Rails 5.2.6, but it has a lot of sense to upgrade from Rails 5.2.6 to Rails 6.0.1 because the MAJOR version has changed and probably we want to take advantage of the new big changes made by this new fancy version. 

Upgrading MINOR and PATCH

Upgrading MAJOR

From here and now, next time you start to work at a new company or you get a new freelance job in Rails you will recognize a good and actively developed project if that project is up to date with the latest versions. 

On the other hand we have the legacy code. This means that we’re working with an old project that is not actively developed in the recent years and you’ll probably encounter some issues related to new versions, or you couldn't use the new things that the software offers. That project probably has some security vulnerabilities or at least some potential issues. 

It’s fair to say that a lot of projects fall into this category. That is because some managers give more importance to the creation of new features and solve current bugs than to keep up to date. And that's ok. What’s not ok is to have some security concerns or bad practices over the project because of that. 

As I mentioned before, you just need to keep an eye on this at least each 6-12 months. Sometimes refactoring the code to the new version is painful, because a lot of changes were made on that latest version. You need to have a strong test suite to smoothly upgrade, and that should be your main concern now. With this prerequisite you could upgrade easily and take advantage of new features.

Talking about upgrading, it’s normally a painful process, where almost all developers and managers try to avoid it because of this reasons:

I lived this process by myself with Rails, and I have to say that I really enjoyed the process and the many things I learned. When you start 2, 3  or 4 MAJOR versions behind the current one it is scary and overwhelming to think about the many changes you’ll need to do, and if you don’t have a strong test suite you won’t know if you broke something. Remember it is better to do this each 6-12 months than wait 5-7 years and fall behind. After this huge amount of time you’ll require a lot of resources to do the upgrade. 

Normally each modern programming language has something called package manager. A package manager is a very useful tool to manage software versions. In Ruby we have RVM and rbenv. In rails we have bundler. In Python you’ll have pip or conda. In Javascript you can use NPM. It’s almost impossible right now to develop software without these package managers and it doesn’t make any sense to do it without it. We’re going to know more about RVM and rbenv in the next blog post. See you then!

Thanks for reading

Daniel M.