We will continue with the second part of our last blog post called Versions & Releases in Open Source Projects. In this case, we'll be reviewing other terms that can help us understand the world of versioning and releases. 

Youtube video about this blog post: https://youtu.be/mGNhSnlCSE0

Versions & Releases in Open Source Projects - Part 2

When we talk about the stable version of a software product, we're referring to a kind of version that we can use for sure; it's a version that is ready and widely tested, and prepared for mass usage. At least these kinds of versions surpass the release candidate, and the testing stage and the software creators refer to this new stage as stable. So, the best practice is to always use the latest 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, the version itself is not receiving any support from the creators, collaborators, community, or maintainers. And why does this matter? It's simple: 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 supported by the community. But, of course, you can always see the latest version inside the software documentation. 

When we're developing software and achieving a certain amount of months or years working in that fancy project or company, the code inevitably gets outdated. However, if we started to work on that project 2 years ago, there are probably new versions available to upgrade.

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 project versions, but it is essential to keep the good practices, avoid security vulnerabilities, and be up to date with the software we use. Of course, this doesn't mean that we have to upgrade the whole project each week or month. But at least we need to check for new versions every 6 months or each year as a minimum requirement.

If you wait for more than 1 year to check for new versions, your project probably will fall in the legacy code category. As you may know, software advance at the 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've learned in the last blog post about semversion, and we studied the concept of MAJOR.MINOR.PATCH, and we know now that probably it doesn't have any sense to upgrade from Rails 5.1.0 to Rails 5.2.6. Still, 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 significant changes made by this new fancy MAJOR version. 

 
Upgrading MINOR and PATCH
Upgrading MAJOR

From here and now, the 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 over an old project that has not been actively developed or upgraded in recent years. As a result, you'll probably encounter some issues related to new versions, or you can't use the new things that the software offers. In addition, that project probably has some security vulnerabilities or at least some potential issues. 

It's fair to say that many projects fall into this category. That is because some managers give more importance to creating new features and solving current bugs than keeping up to date with the software versions. And that's ok. What's not ok is to have some security vulnerabilities or bad practices over the project. 

As I mentioned before, you just need to watch this at least every 6-12 months. Sometimes refactoring the code to the new version is painful because many changes were made on that very latest version. Therefore, you need to have a robust test suite to smoothly upgrade, and that should be your primary concern now. With this prerequisite, you could upgrade easily and take advantage of new features.

Talking about upgrading, it's usually a painful process (as we mentioned before), and almost all developers and project managers try to avoid it because of these couple of 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 version, it is scary and overwhelming to think about the many changes you'll need to do or things that can break up, and if you don't have a robust 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 massive amount of time, you'll require a lot of resources and time to do the upgrade. 

Typically each modern programming language has something called package managers. A package manager is a handy tool to manage software versions. For example, in Ruby, we have RVM and rbenv. In rails, we have bundler. To deal with ruby gems, we have RubyGems. 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 will know more about RVM and rbenv in future blog posts. See you then!

Thanks for reading
Daniel Morales