The Chief Architect of the Java Platform Group Mark Reinhold has recently blogged about his vision about the future of Java’s release management. The ideas generally received positive feedback except his idea of using time based versions.

Semantic versioning doesn’t work well with time-boxed releases. #javatrain https://t.co/lJrEomjf8f

— Mark Reinhold (@mreinhold) September 6, 2017

Time based versions are gaining popularity. We see more products changing from semantic versions to YY.MM formatted ones. But why ?

Why do we choose one over another ?

We have to first think about the version itself.

Why do we provide a version string ?

Because, we think that giving a unique string indicating a certain point in a product’s lifetime is an important information for the consumer of that product

So, version string is actually a message, right ?

Yes. It is a message from the publisher to the consumer.

If it is a message, what should it tell ?

Now this is the tricky part. The content of the message depends on the audience who uses it.

Semantic versions typically convey the message about the composition of a new release when compared to the previous version. Is it a major release ? Should I expect potentially breaking changes ? Or is it a minor release ? May be it is just a bug fix release which is quite safe to consume without worrying that much.

This kind of information is typically useful for the developers because it directly affects developer’s decision on the product.

What kind of message time based releases tell ?

We use time based releases when the age of the product is the most important message to the consumers.

It basically tells whether you use something old or new. This is clearly a marketing driven approach.

Time based versions put psychological pressure on people by subliminally telling that they are using an old software and they should better get the new thing. Pushing people to use the most recent version of the software is obviously every vendor’s dream since it decreases maintenance costs greatly. Time based versions work well with products that target end users.

So, should Java have semantic versions or time based versions ?

Developers consider themselves as end user for some products. Operating systems, code editor, or keyboards are like those.

For example, Intellij IDEA has switched to time based releases in 2016. This was a correct decision. As a customer of IDEA, the most important thing I care is to get the latest version of the editor, in order to improve my productivity. I am an end user of the IDEA and I use it to make software. I don’t care how IDEA works, I just customize and use it. Changes to IDEA don’t affect my product. If I feel unsatisfied, I can just use something else. Same goes for Emacs. I never cared about the Emacs version, I was always using the latest one.

On the other hand, I put hibernate, log4j, jackson etc in to the software I make, which is based on certain version of Java. I am not an end user of them. I care about how they work, I care about the changes happening to them. Every change they have, brings a potential impact on what I make.

There is a clear difference here.

Java is not an end user tool for developers

Being an end user or not is so slippery area. For example: I can be an end user for Eclipse, but also I can be a developer who uses RCP to develop an application. Then Eclipse becomes much more than an editor for me, it becomes the part of the creation rather than being a tool for creation.

Java isn’t perceived similar to IDEA in the eyes of developers. Developers do care about changes happening to it since it directly affects their products.

Telling year and month of the release in the version string doesn’t provide more information than before. It even hides information that was previously obvious. I know what to expect when I see JDK1.8.0_131, but a JDK 18.04 tells me nothing important for my development purposes.

Note that this has nothing to do with having 6 month time-boxed releases. Actually I like it. But then, what would I prefer ? Best of both worlds, if possible.

I would prefer keeping semantic versioning and bumping minor number every 6 month by the total amount of added language features. If a language feature requires byte code change, than major number can be bumped while resetting the minor number.

What about having no version at all ?

This is the best thing! It means that your consumers don’t even need to care about it at all. If JDK can guarantee that all new versions are %100 safe to use, I would never worry about the version and just stick with the latest. Currently this more or less happens with browsers. It can happen with operating systems as well, but changing the name from Android N yo O, or IOS 10 to 11 has marketing value so they are still used. Same value don’t exist for browsers.

Conclusion

The version string is a message targeting the certain interest of the audience. If the consumers care about freshness, or if we want them to care about that, or if semantic versioning has no meaning for them, time based versions can be used.

If the composition and individual changes in the software is much more important than the release date, semantic versioning works better since it tells more helpful information.

Therefore, I hope Java keeps using semantic versioning while switching to 6 month time boxed releases.