Adopt Calendar Versioning Schema (CalVer) for hashgraph/hedera-services repository

[tannerjfco]

Description:

This HIP proposes to transition the hashgraph/hedera-services repository versioning schema from Semantic Versioning (SemVer) schema to Calendar Versioning (CalVer) with an approach modeled similarly to the Ubuntu Release Cycle that is compatible with most of the rules and priniciples that SemVer provides.

Related issue(s):

Fixes #

Notes for reviewer:

Checklist

• Documented (Code comments, README, etc.)
• Tested (unit, integration, etc.)

[netlify]

✅ Deploy Preview for hedera-hips ready!

Name	Link
🔨 Latest commit	27094b8
🔍 Latest deploy log	https://app.netlify.com/sites/hedera-hips/deploys/65ba8b1d7da70200082ea946
😎 Deploy Preview	https://deploy-preview-851--hedera-hips.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[leninmehedy]

Based on format notations of CalVer, shouldn't it be YYYY-0M-0D-z<-modifier>?
YYYY: 4 digit year (Let's not introduce the possibility of 2K bug again)
0M: Zero padded month (01, 02, 03,...,11, 12)
0D: Zero padded day (01, 02, 03, ....30,31)
z: Patch number (starts at 0)
modifier: alpha | beta | rc1

[tannerjfco]

You can go either way on the Year part with CalVer

As seen in the case studies below, projects have found more than one useful way to leverage dates in their versions. Rather than choose a single scheme, CalVer introduces standard terminology for developers, in addition to the "semantic" versions:

YYYY - Full year - 2006, 2016, 2106
YY - Short year - 6, 16, 106
0Y - Zero-padded year - 06, 16, 106
MM - Short month - 1, 2 ... 11, 12
0M - Zero-padded month - 01, 02 ... 11, 12
WW - Short week (since start of year) - 1, 2, 33, 52
0W - Zero-padded week - 01, 02, 33, 52
DD - Short day - 1, 2 ... 30, 31
0D - Zero-padded day - 01, 02 ... 30, 31

So you can pick and choose the specific format that works best for your project and its community.

4 digit year (Let's not introduce the possibility of 2K bug again)
As shown above, you can go either way on this. I am suggesting we use the 2 digit year (at least for now) for the following reasons:

1. It's shorter, simpler, and easier to communicate
2. It's good enough for Ubuntu, one of the most popular Linux distributions in the world
3. A Y2K-style bug is not a concern for roughly ~70 years. By then, Ubuntu and other projects using the 2-digit format will have to come to a resolution
4. I don't think choosing 2-digit today necessarily discounts the possibility of switching to 4-digit at such point it becomes more desirable or necessary. At such point we could potentially go from a 99.0.0 release to the next release being 2100.0.0. So long as the next major version number is bigger than the last, the rules should still apply and the versions should be evaluated properly. It is possible there could be gaps in some SemVer implementations that do not properly handle 4 digits in the major versions, but if those gaps do exist I would think they need to be fixed eventually

TL;DR I don't think 2-digit year puts us in a corner today and we can still go to 4-digit year later. But both options are valid under CalVer scheme

[tannerjfco]

Quick follow up: Further discussions around this particular topic have surfaced that the year 2100+ is already accounted for in the CalVer spec: both the "short year" YY format and "zero-padded year" 0Y format examples demonstrate these 2-digit formats can increase to 3 digits when the need arises:

YY - Short year - 6, 16, 106
0Y - Zero-padded year - 06, 16, 106

So if we chose the 2-digit year format today as proposed, the first release for the software in the year 2100 would either look like 100.1.0 (using short-year format) or 100.01.0 (using zero-padded-year format)

With that understanding of what the spec provides out of the box for us, I believe the tl;dr is now along these lines:

1. CalVer already solved the year 2100+ problem should a project choose to use either 2-digit year format it provides
2. Additionally, another option still exists where the 4-year format could be adopted in the future if desired.
3. In addition to both options 1 and 2, a 3rd option exists where the project itself could be renamed / started fresh in some way - start the year 2100 by taking the end result of version 99.12.x, start a new repo with a refreshed name, and start the versioning back at 00.1.x, archiving the previous project for posterity

The 3 options are ranked in level of disruption: option 1 should provide little-to-no disruption to the project. Option 2 could require some version comparison logic or dependent libraries to be updated to support a 4-digit number in the "MAJOR" position. Option 3 is highly disruptive, but depending on where the project goes that far into the future, circumstances around or even before the year 2100 could make such a route desirable. There is no way to say from where we stand today.

I think this gives us enough answer to this question to be ok to proceed and mark this piece of feedback resolved. Thanks for raising the feedback though, it sparked some very good discussions and thinking around this particular problem!

[rbair23]

I agree, we passed the "1.0" point a long time ago.

One thing to keep in mind is that the node software has two versions -- the software version, and the HAPI version, and they need not have the same versioning scheme. The HAPI version is used to communicate to users of HAPI the compatibility and maturity of the HAPI itself, while the node software version communicates the version of the node software. I suggest that HAPI is semVer, while the node software is calVer.

This is a very common approach in web2 software development, where the software version is one value, and the API version something else, as in /some/path/v1/myApi where the API version is baked into the URL.

[tannerjfco]

@rbair23 I believe your thoughts on this are already captured in the HIP via 1)a) (the line right under the one you commented on here). At least in terms of stating "the node software project AND its public APIs are both in fact pretty stable". If you think there are any revisions/additions that would help describe this or your thoughts on what should or shouldn't be SemVer or CalVer, I'd appreciate any suggestions you may have