Versioning Change - please don't use +

I see you have changed your versioning system for RStudio Desktop.

If possible, I would request to please avoid using non-numeric characters in the versions (ie., +), as that breaks many automated processes for testing and deployment (autopkg, JAMF, etc).

1 Like

Thank you for your feedback! We updated to Calendar based versioning (see our blog post for more info) for this release, which introduced some complexities that ultimately ended in the addition of the + character to ensure that our version still follows the SemVer spec, which is used by many version parsers.

Unfortunately, we can't make changes to the versioning scheme for the 2021.09.0 release of RStudio Desktop, however we can modify the file names so that they don't include the + character, instead replacing it with a - character. Would that resolve the issues you are experiencing?

For example, the Ubuntu 18+ package for the current release (2021.09.0+351) would become rstudio-2021.09.0-351-amd64.deb.

HI Maria,

Thank you so much for getting back with me.

My first desire would be an underscore (_), but a dash may work as well. I know we have had success with underscores on other packaging involving AutoPkg and JAMF, which is where this has created an issue for us.

I very much appreciate your contacting me back about it!

SJ

No problem! The files with a - character are available to download now. It will take some time to update all the documentation on the website, but in the meantime, can you check whether the modified file name resolves your problem?

Here is the download link for RStudio Desktop for MacOS:
https://download1.rstudio.org/desktop/macos/RStudio-2021.09.0-351.dmg

If that is not the operating system you are using, you can simply replace %2B with - in any of the existing download links for the 2021.09.0 release.

Thank you. Is it possible to move to just having the build as the next set of digits, ala
Rstudio-2021.09.0.351.dmg
That would be the best of all actually.

The version is also reported with + and it breaks idempotency in Ansible Playbooks, is this also going to be changed to "-" or just the installer's file name?

ubuntu@ip-172-31-47-22:~$ sudo rstudio-server version
2021.09.0+351 (Ghost Orchid) for Ubuntu Bionic

Hey @andresrcs ! Do you mind explaining a bit about which ansible playbook you're using? Is it open source so that we could take a look at it?

We are wondering if it does a version comparison or if it bases idempotency on other things like (1) a download file existing or (2) an installation directory existing (as is the case here - albeit old)

Moreover, if it does a version comparison, if an apt or yum repo would help in the matter (as that is something we are aiming to have in the future)? Generally speaking, our plan at present is to have the installer's file name to have a - and the version to have the + (so that it is compatible with semantic versioning and rpm/deb version comparisons along with our daily and preview builds).

The way we are planning to do this comparison in our docker images is to define the desired product version (i.e. with a +) and then replace with a "-" when we build URLs (which is nice because + signs have to be URL encoded in HTTP requests, anyways).

Any more information you can provide about your playbooks here would be super helpful!! Thanks!

Yes, it is just a playbook I wrote for a blog post, it is aimed to beginners so nothing fancy.

Yes, it checks if the current installed version is the same as the version the user is trying to install, I can definitely work around this with a little regex but I just want to be sure it will be actually needed (if you change to "-" in the reported version as well as in the file name it wouldn't need any change at all).

That would be awesome, I guess the "package" module would take care of idempotency for free in that scenario.

Awesome!! Thank you for sharing that! Yes, I think the nice thing here is that it looks to me you could either make the version comparison into a regex or you could do this type of a replace when you download the file:

The benefit here is then you retain the "actual" version for use elsewhere (i.e. the test):

Thanks!, this looks like a simpler solution, although, having to use it still fills a bit hacky. I hope the apt repo comes soon so we can get a way seamless workflow.

Could you please give us an update on this, when it's carved in stone? I just find out I can use the urlencode filter (Jinja2 in Ansible) so I would only need to construct the download link with {{rstudio_version | urlencode}} if both version and filename are the same (it currently works because both links with "+" and "-" exist, but I don't think it is going to be the case in the future) but if they are not I would have to use {{rstudio_version.replace ('+', '-')}}.

Is there a reason it cannot just be .build number?

ie., Rstudio-2021.09.0.351.dmg
YYYY.MM.Version.Build

That would likely solve a lot of it and be more in line with standard semantic versioning.

We are done for now (until we get an apt / yum repository) - the version number is 2021.09.0+351.pro6 and the package will be written as 2021.09.0-351.pro6. We will maintain this convention going forwards.

Moreover, you will notice that all of our products are adopting similar conventions here, although how build metadata is handled varies slightly by product. We are shooting for consistency as much as we can :grinning_face_with_smiling_eyes:

The 351 build number is for the open source side of our repository. The pro6 suffix is the 6th build of the "pro" line. In the past, both build numbers were present, but ambiguous. We decided on adding the "pro" piece to make it clear that that is the "pro" build number, and that this is a pro package.

In the open source builds, you can see that we do just have the 351 component: Download RStudio Server - RStudio

That said, our product is versioned as 2021.09.0. The build numbers should have little consequence to users, as we will no longer be releasing multiple versions with different build numbers.

In order to be compatible with semantic versioning (characters after a dot or dash are not interpreted properly) and work with the different packaging paradigms (.deb, .rpm, etc.), a plus sign was required. In fact, this is defined in semver:

Build metadata MAY be denoted by appending a plus sign and a series of dot separated identifiers immediately following the patch or pre-release version. Identifiers MUST comprise only ASCII alphanumerics and hyphens [0-9A-Za-z-]. Identifiers MUST NOT be empty. Build metadata MUST be ignored when determining version precedence. Thus two versions that differ only in the build metadata, have the same precedence. Examples: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85, 1.0.0+21AF26D3—-117B344092BD.

I hope that clears things up! If there's anything we can all take away from this - it is that the old adage that "there are only two things hard about programming" should be three:

  • naming things
  • cache invalidation
  • versioning
  • and off-by-one errors
1 Like