One of the first things you need to understand in the development world is that open source programming languages and the software we create are always attached to a given version. Versions means the normal evolution of the tool, language or software. The tools we create are not static, it always needs to improve and enhance their behavior and results. 

For this reason we always see some kind of cryptic versions like 1.0.3, or 5.2.4 or even something more difficult to understand like 2.5.6-rc. This is also called releases. For instance if we go to this page: https://www.ruby-lang.org/en/downloads/releases we can see the different Ruby versions/releases over the years and you can see something like Ruby 3.0.0-preview2 or Ruby 2.6.0-rc2. If we go to this other one: https://weblog.rubyonrails.org/releases/ we will encounter an overwhelming amount of content related to all of the Rails versions over the years. 

If we are just starting, or even if we have some expertise in the field, this is a big amount of content to consume, urdestand or even test. To feel less overwhelming by this, we need to understand some basic concepts related to versioning or releases

When you install for the first time a programming language, tool, software or library in your operating system the version installed is almost always the stable and last version (obviously if you don’t type any particular version to install). When we talk about stable we are talking about something we can use for sure. Is a version that is already tested in production and we can be confident that we won’t encounter any bugs related to versioning or other things. Is the default and recommended installation. However in some scenarios you need to be careful about the version you are installing because you can find some gotchas like this:

Now that we understand a bit better versioning, it's time to see the next fancy term: Changelog. To understand this word we need to refer to something very common in software development: Logging. In computing a log file is a file that records either events, other runs or messages. Logging is the act of keeping a log. But we’re talking about Change-log. 

When we are talking about versioning we will encounter this useful file named Changelog where at a high level we can see the changes made inside the software for this particular version. So, if we see the Changelog of the Action Cable module in Ruby on Rails up to version 5.1.4 https://github.com/rails/rails/blob/v5.1.5.rc1/actioncable/CHANGELOG.md you can read the changes over the versions in that module

It's important to note that not all languages, tools or software has this Changelog file, or it can be named differently. For instance in Ruby you can see something like this: https://www.ruby-lang.org/en/news/2021/07/07/ruby-3-0-2-released/

In this case if you hit that link, you’ll be redirected to Github with all the commits of this particular release. Sometimes is more difficult to read and understand the changes on this way, but is what we have and if we need to know the changes we need to go through the commits

The next term we need to understand is Semversion. We want to decrypt the fancy numbers like 5.2.1 or 6.0.1. Let’s go ahead. Semversion is equal to Semantic Versioning and you can read the numbers like so: MAJOR.MINOR.PATCH. Source: https://semver.org/ 

Almost all new languages, tools and software follow this semantics

Release candidates make reference to agile software development and is the situation when the new version is almost ready, is already tested and has a low number of bugs. This doesn't mean that the version doesn't have any issues at all. It means that we need to act carefully with these versions, because it is a candidate, but is probably not completely finished yet. The main purpose of this type of versions is to spread among early adopters, who are willing to use it with dummy or even real world projects in a dual booting mode or in different environments like staging and provide feedback to the creators

If we see the above image, we have two main divisions: 

Source: https://en.wikipedia.org/wiki/Software_release_life_cycle

“A release candidate (RC), also known as "going silver", is a beta version with potential to be a stable product, which is ready to release unless significant bugs emerge. In this stage of product stabilization, all product features have been designed, coded and tested through one or more beta cycles with no known showstopper-class bugs”.

The way we can differentiate a release candidate in the semversion jargon is with the word: -rc

The release notes are very similar to Changelog. However in this case we can see the overall changes, not just a module change. This is the kind of notes we need to check when we want to upgrade our current version to a newer one and see if something can break our code. Here we can see the release notes of Rail 6.0 https://guides.rubyonrails.org/6_0_release_notes.html

As the same notes say: “These release notes cover only the major changes. To learn about various bug fixes and changes, please refer to the change logs or check out the list of commits in the main Rails repository on GitHub.”

Thanks for reading!

Daniel M