OHDSI Home | Forums | Wiki | Github

Unified version numbering

Developers
#1

I’ve currently not been very consistent with version numbering, but have decided to try and follow the version numbering as detailed by Karl Fogel:
http://producingoss.com/en/producingoss.html#release-numbering

Basically, a version number has three components:

  • New micro versions (e.g. from 4.3.2 to 4.3.3) indicate bug fixes only. No new functionality, and forward and backward compatibility are guaranteed
  • New minor versions (e.g. from 4.3.3 to 4.4.0) indicate added functionality. Only backward compatibility is guaranteed
  • New major versions (e.g. from 4.4.0 to 5.0.0) indicate major revisions. All bets are off in terms of compatibility

You can add ‘alpha’ and ‘beta’ to release numbers as well to indicate development stages of the release (e.g. 5.0.0 alpha)

Shall we try and follow this practice throughout OHDSI?

1 Like
#2

Great idea martijn, I agree that following this convention could help us all a lot.

#3

Martjn,

I also agree fully. I happened to be at dinner with Burke from OpenMRS when I got this message and gave him a quick look. He confirmed they follow the same versioning, only difference is they use the term ‘Maintenance version’ instead of ‘Micro version.’

Thanks for bringing this up. We may need some help putting it into action consistently but I assume you wouldn’t mind taking the role of reviewing update naming for a while until we get on the right track?

Jon

#4

Sure, happy to help! However, I can’t keep an eye on all repo’s so if someone want to name a new release I suggest the first couple of times we discuss it in this forum.

#5

Agreed. Thanks Martijn!

#6

I just ‘released’ version 1.0.0 of Achilles, if for no other reason than we will soon have Achilles version 1.1.0, which does everything 1.0.0 does, but also runs on the CDM v5. (So added functionality, but backwards compatible).

I was just wondering: Achilles and AchillesWeb are closely linked. Should we also release an AchillesWeb version 1.0.0 and 1.1.0, even though AchillesWeb hasn’t changed? If not, how do we make sure people know which version of Achilles goes with which version of AchillesWeb?

#7

Hmmm, I’m getting the feeling you are calling for a unified OHDSI application… :slight_smile:

#8

We put together a template for github readme and wiki documentation yesterday. Part of the template has a section for dependencies. I would imagine we would list the version dependencies in the documentation. If there are no required updates to Achilles Web then I wouldn’t require people to update the web application with the new version of the R package.

#9

I guess we’d also need to mention these dependencies as comments on the releases, since they will change over time (and a release is a snapshot in time)?

Speaking of which: will there be an AchillesWeb release soon?

#10

Definitely will need to mention the dependencies and keep the github readme and wiki up to date. There is not a pending release of AchillesWeb. There are a quite a few issues/improvements suggested in GitHub and it would be great if anyone on the development list here would like to take some of them on. The current focus is an end of year Hermes release. We’ll need to look into a place to store our release schedule, on the wiki perhaps?

#11

What I meant is simply pushing the 'Create a new release` button now, so the current version as it is is tagged. Already many people have used today’s version, but we do not have an explicit reference to what it is they’re using. We can then also say on the Achilles repo: will work with AchilesWeb version 1.0.0.

#12

Oh, done.

#13

I come back to this post over and over. <3

1 Like
t