wyDay blog

Hey everyone!

Today we've released version 26.0 of TurboActivate, TurboFloat, and TurboFloat Server. Get them now on your API page. Upgrade to version 26.0 immediately for the best performance and reduced customer complaints.

Among the many performance and security improvements and bug fixes, we've also added TLS 1.3 support for all platforms that support it (Linux, BSD, macOS, and Windows 11 and newer). This means faster and more secure connections to the servers. Old Windows (10 and lower) will fallback to TLS 1.2.

Also, we've added ARM64 support for customers targeting the FreeBSD operating system.

And, despite the "major" version bump (the last version was 4.4.4 and now we're releasing 26.0), there are absolutely no breaking changes!

"Semantic" versioning is a joke

Why did we bump the "major" version from 4 to 26.0 if there are no breaking changes? Because we released TurboActivate / TurboFloat 4.0 in 2016! That's almost a decade ago. We've been releasing "minor" versions with so many feature improvements and bug fixes in the time between, but we've always kept that "4" in front. But we want people to upgrade, so we're changing that 4 to another number.

Now the "major version" is just matching the year to make it easier at a glance for customers to know just how out of date their integrations are and fix them.

That's it: progress has been made and you should upgrade if you're on an old version.

If you're in the software programming field (and you likely are if you're still reading this), then you've likely heard of "semantic versioning". There are books, websites, and far too many hours of videos dedicated to the topic, but briefly it can summarized as the following (by the guy who birthed the idea):

Given a version number MAJOR.MINOR.PATCH, increment the:

1. MAJOR version when you make incompatible API changes

2. MINOR version when you add functionality in a backwards compatible manner

3. PATCH version when you make backwards compatible bug fixes

In other words, this is an engineer's solution to a marketing problem: well meaning, but wrong and naive.

Why is "semantic" versioning a thing? And why is it a wrong thing?

Semantic versioning is a thing because the guy who wrote a blog post ... I mean, "spec" ... about it is the co-founder of GitHub. Famous guy in programming writes something about programming and programmers glom onto it. Tale as old as time.

This guy is also a creep and a credibly-accused sexual harasser who got pushed out of GitHub for his — as the lawyers for GitHub wrote — "mistakes and errors of judgment" (i.e. sexual harassment).

But, "semantic" versioning isn't wrong and naive because Tom Preston-Werner is a credibly-accused sexual harasser and an all-around creep. Semantic versioning is bad because software is written by humans, purchased (or acquired) by humans, and put into commission and/or used by humans (or used by bots written by humans).

It's a robotic non-solution to a human problem. Namely: how do we convey when, how, and who should upgrade this software.

And the answer is simply that you cannot communicate all of those things through a version number. A few digits and some periods don't have enough expressiveness to reflect the complexity of software. The most you can communicate with a version number is that it's a different version number (and that's only if the customer even knows what version they're on!)

And, most importantly, "patch" and "bug" fixes can (and do) introduce "breaking changes". Sometimes the "breaking changes" only effect people doing silly things (like depending on obviously buggy behavior), but more often than not the "breaking changes" are a result of the bug fixes interacting with other software on the computer (whether the OS, the kernel, critical services, etc., etc.) that have their own bugs.

In other words: the world is complex. And software lives in this world. Trying to reduce this complexity to a version number is silly.

And because there's an XKCD comic for every silly programming controversy:

Lastly, Tom himself wrote another "spec" (blog post?) contradicting his original blog post ("spec"?) saying "Major version numbers are not sacred."

Yeah, no shit.

Now we have 2 contradicting opinions ... I'm sorry, "specs" ... on the same subject written by the same person. And he refuses to admit he was wrong. That's not entirely a surprise coming from Tom and his past credible accusations of sexual harassment and lack of acknowledgment or human emotions like, say, remorse.

A cynical person might say the "S" in "semantic version" stands for "sexual assault", but we all know it stands for "supply chain attack". See all the countless semantic version repositories (NodeJS's NPM, Python's pip, etc.) where an entire library was replaced with a malicious version all without "breaking" the version number.

Why all this over a version number?

We've never used "semantic" versioning and never will. We've always viewed it as a silly idea. However, because of the cargo-cult tendencies of the software industry, we get asked why we don't use it. Unfortunately an eye-roll isn't a good enough answer. So now you know. 🤷‍♂️

Wishing everyone happy holidays, happy new years, and a life filled with just a little less bullshit!

- Wyatt O'Day
Founder & CEO of wyDay

We've done a ton of work in 2024. A lot of it was behind-the-scenes. In addition to putting the final touches on LicenseChest, here's a few broad things we've been working on:

1. Speed & security: Our servers respond quicker and handle larger loads (all while using less CPU and memory). This means we can serve more customers more quickly. For you this means snappier management of your licenses. For your customers this means even faster activations and verified trials.

   Speed of our servers is something we spend a lot of time and money on. Not only does it make things faster for your customers (activations and deactivations happening faster than the a blink of an eye) but it makes us able to handle larger amounts of customers and “frees up” server resources to handle other planned features.

   And this choice of solving speed with engineering refinements (rather than just throwing money at the problem in the form of newer and more servers) has the added benefit of getting more eyeballs on our code and developing better processes for verifying and securing our code.

   This is a long way of saying we’ve made our services significantly faster and more secure. And we’ll continue to pour a portion of our time and money into making things even faster and more secure.

2. Add TLS 1.3 support to curl on Windows: We've recently added TLS 1.3 support to curl on Windows. Curl is a popular command line tool for downloading files on every platform. We didn't create curl, but we spent the time and money to add TLS 1.3 support to Windows (SChannel specifically) because we (and many other companies) use the curl library to "talk" to the internet.

   So, not only will TurboActivate, TurboFloat, and the TurboFloat Server all support the faster and more secure TLS 1.3 standard, but other apps that use the curl library will get those benefits too.

   We've continued upon our initial contribution with additional refinements and bug fixes (working around Windows bugs, for instance).

   That's part of the beauty of open source: mutually beneficial self-interest.

3. Accessibility: We’ve made our forum software more keyboard and screen-reader accessible. This makes things better for everyone. Also, because our forum software (soon to be open sourced) shares components (both UI and backend) with the soon-to-be-released LicenseChest and refreshed LimeLM interfaces these accessibility changes will benefit all of our customers (and your customers too).

   Accessibility positively effects everyone whether you’re “fully able bodied” or you have any type of neuro-divergence or physical needs outside the “norm”. Our products aren’t perfect, and there’s always new work to be done, but this has been a focus of our company.

4. TA / TF / TFS 5.0 releases for Windows: We’ve released TurboActivate, TurboFloat, and TurboFloat Server 5.0 for Windows. We’ve released it early (before the Unix builds are finished) to work around broken network drivers that Intel and Qualcomm have been releasing lately. Get them now on your API page.

   We’ll release the Unix builds of TA/TF/TFS soon and we’ll have the updated changelog and blog post announcing it when it’s done.

End of 2024 and beginning of 2025 will bring even more behind the scenes progress (TLS 1.3 support for other Unix platforms, updated TA, TF, TFS builds, even faster server performance, etc.). Plus we'll actually release the updated LimeLM interface and LicenseChest.

We also have a couple projects that have been brewing that we think people will like. More about those in the coming months.

We’re very happy with what we’ve accomplished this year. While we always wish we could get more done, but we think we’ve had a good balance of features, speed improvements, and accessibility improvements this year.

TurboActivate and TurboFloat 4.1 are now out! This release is a huge leap forward in quality and features and sets the foundation for the new product releases that will be rolled out over the next 2 months.

So, wait no longer: get the latest TurboActivate and TurboFloat on your API page.

If you're not already a LimeLM customer, sign up now for free!

Here are the big "marquee" features of this release:

NodeJS support

We're proud to be the first commercial licensing to offer true hardware-locked (a.k.a. node-locked) licensing and floating licensing (a.k.a. concurrent licensing) for NodeJS. This means it's easier than ever to sell your NodeJS and Electron apps. You can write in pure JavaScript and let us handle all of the platform-specific details that need to be figured out for fast and accurate licensing.

Learn more over in our "Using TurboActivate with NodeJS or Electron" article (for hardware-locked licensing) and our "Using TurboFloat with NodeJS or Electron" article (for floating licensing). These articles and the accompanying example apps will show you everything you need to know to add true node-locked and floating licensing to your NodeJS app whether you're on Windows, Linux, macOS, or FreeBSD.

Which brings us to our next big feature:

Full, native FreeBSD support

In addition to supporting the "big 3" operating systems (Windows, macOS, and Linux) with this 4.1 release we've added support for FreeBSD! All of our products now run natively on FreeBSD 10.x and above (no Linux compatibility layer necessary).

You can download the latest versions on your API page in LimeLM.

TurboFloat Server behind HTTPS

Prior to this release of TurboFloat Server version 4.1, the TurboFloat Library and TurboFloat Server only "talked" over encrypted raw binary. This was perfectly fine when the TurboFloat Server was behind a corporate firewall and all of the "clients" existed in the same network.

Things got trickier when a corporate end-user decided to host their TurboFloat Server on a public facing computer and their employees ran your app from different networks. If they had a "direct" connection to the server running the TFS instance (whether on the same network or through a VPN), then everything worked fine. But things are rarely so easy in a corporation. Inevitably communications would need to go through a labyrinth of proxies. And, unfortunately, proxies rarely support "raw" transmitted data.

The solution is letting your app (using the TurboFloat Library) talk to the TurboFloat Server over HTTPS. Read more about how to do it here: Configuring TurboFloat Server for HTTPS communication.

Now corporate clients with complicated proxy setups (or anyone else) can have all of the communication happen over HTTPS.

Better client-side trial fraud detection, real-time trial expiration

We're also excited to add improved client-side date/time fraud to the timed-trials functionality in TurboActivate. We improve client-side fraud detection with every release of TurboActivate, but this version took a leap forward.

Additionally, we've added a new function "TA_SetTrialCallback()" that gives you real-time notifications of trial expirations and fraud. This means there's no more need to "poll" TurboActivate functions for the life-time of your process. Just, call that function once, and let TurboActivate handle it.

More consistent Linux ARM builds

Prior to this 4.1 release we made the following ARM builds of our products:

• armv4t, 32-bit little-endian, soft-float

• armv7-a, 32-bit little-endian, soft-float

• aarch64, 64-bit little-endian, soft-float

But we've found this doesn't match the use-case for most of our customers on these platforms, so we've added "hard-float" version for everything other than the armv4t target, and we've added an armv8-a, 32-bit build. So, here's our new targets:

• armv4t, 32-bit little-endian, soft-float

• armv7-a, 32-bit little-endian, hard-float

• armv8-a, 32-bit little-endian, hard-float

• aarch64, 64-bit little-endian, hard-float

What this means in practice is that you can sell your app and target distros like Raspian (and all other popular arm-based distros) without having to re-target your app for "soft-float" support.

A ton more...

In addition to the big features listed here, we have a ton of quality improvements and tweaks to provide a better experience for all end-users. Read a condensed list of changes here for TurboActivate and the changes for TurboFloat.