Published by Dirk Paessler
Last updated on March 03, 2022
•
11 minute read
Today we are proud to announce the soon release of the next major version of PRTG: Version 12.2.
Dirk Paessler, CEO of Paessler AG, talks about the new PRTG version as well as our changed release strategy.
What? Version 12.2? Where are Versions 10, 11, and 12.1?
OK, let me explain: Our primary goal at Paessler is to serve our customers as well as we can. On the technological side this means providing new features, support for new technologies, as well as frequent and quick bug fixes, at the same time improving the quality of the software.
Development and Release Policies
Under our former internal development strategy and rollout methodology we could only improve on one of the two parameters at a time while keeping a high pace: Provide new features quickly OR improve code quality.
- We could either take a long time to add several new features (and then roll out code that had been operational for many months solely in our own labs)
- OR we could quickly deliver new features one-by-one (yet sacrificing parallelized development by different team members).
For example, this was the reason why our support for VMware 5 (that became necessary due to changes in the VMware system in summer 2011) came 3 months later than the initial release of PRTG 9. This made everybody unhappy, so we wanted to improve on this.
Continuous Rollout
Do you use Google Mail, SalesForce, Facebook, Twitter, etc.? If you do, you have already had first-hand experience with most recent cloud services. One of the big advantages these services offer is that users do not manage software updates-one merely logs in and always uses the latest version available. You don't even realize that today you are using a different version than yesterday. For such SaaS (software as a service) providers, the term "continuous delivery" describes the current state-of-the-art software delivery process. Instead of delivering just a few versions per year, with massive changes between them, the modern, agile software development process calls for many small iterations when creating and delivering software to the customer. Companies like Facebook or Google sometimes use hundreds of different software versions distributed over their servers at the same time. They do this to test new code and new features before they roll them out to all servers.
Because our PRTG software must be run "on-premises" (i.e. within our customers' networks) we can't use the continuous delivery concept. However, with our "continuous rollout" concept we will come quite close!
We all know what "auto updating" is. It has become a common process in the computer world. For example, Microsoft ("Windows Update") and many other operating system vendors have been providing updates like this for years. Cutting edge projects like "Google Chrome" and, shortly, "Mozilla Firefox" or "Internet Explorer" are using auto update strategies as well.
Three Release Channels
Remember, our goal was to provide new features and fixes faster AND with better quality. So we will actually provide three "channels" for our software, so every user can choose either maximum stability, earlier access to features, or a mixture of both:
- The "Stable" channel will give you the most conservative, best tested version of PRTG. We will update this channel with new features about once or twice a month and whenever an important bug fix makes it necessary (just like we did in the past with PRTG 8 and 9)
- The "Preview" channel will be updated about once a week, offering the latest features and fixes that have already been tested successfully in our labs. It will allow you earlier access to new features and will allow us to test new features "in the wild" sooner.
- The "Canary" channel will provide "Nightly Builds" and may be updated as often as several times per day. This code comes directly from our development floor. This channel may contain elements that might not work yet or that have not been tested extensively, and the software should only be used in test scenarios. Computers running this version may even crash (rarely). As such, it should NEVER be used on production systems.
Depending on this setting of your PRTG installation you will be automatically notified upon release of new versions available in your channel. PRTG even includes an option, allowing one to install the new version automatically, as soon as it becomes available.
Why do we Publish the "Canary" Channel?
What's special about monitoring software like PRTG is the heterogeneity of the real network world out there. Most vendors do not talk about this openly, but we all can only test our software products on a fraction of potential network devices. There are thousands of vendors with a myriad of products that PRTG is intended to work with. Of course we already have a huge lab with a numerous hardware and software from many different vendors. But we need our customers' assistance with this. Everybody benefits from this crowd sourcing approach. One of the main objectives is to provide a way that our users can get involved in this process.
We are asking our users to run the Canary version in their networks, on a dedicated test system (or VM), and provide their feedback on the software. To encourage this, freeware installations of PRTG will provide 30 free sensors when the users switch their test installations to the "Canary" channel. This means that you can run the freeware edition with 30 sensors (instead of 10 sensors) for free alongside your commercial installation. Your feedback will help us improve the software and, in the end, everybody will profit from this approach.
By the way: Where does the name "Canary" stem from? Canary birds were used in coal mines as sensors for dangerous gas concentrations (they are sensitive to methane and carbon monoxide). As long as the birds kept singing, the miners knew their air supply was safe. A dead canary signaled an immediate evacuation. Google calls its experimental Chrome branch "Canary", as well.
Why did we Skip Versions 10 and 11?
There is a clear trend in the software industry to become more and more "version agnostic". With "continuous delivery" and "auto update" becoming the mainstream concepts it doesn't matter which exact version you're using anymore. You are just using the current version. Period. For example, think of Firefox or Chrome: Do you know by heart which version you are currently using? Version 8, 9, 10, 11, or 12? It does not matter!
From now on we will use the current year and quarter as the PRTG's version number. Since the first release of version 12 will be taking place in May 2012 (Q2), it will be called version 12.2. On July first 2012 our nightly build will carry the version number 12.3, and so on. This gives you a rough idea how old a PRTG version is, but soon you will no longer give version numbers a thought, anyway.
In my next post I will talk a little more about PRTG 12.2. Stay tuned.
You there!
