Version 10 has disappeared

[getontoit99]

Great announcements last year about Veeam Availability Suite version 10 coming soon, and all the new functionality.

We were particularly pleased with "Native Support for Cloud Object Storage (Azure Blob) as an archive tier in Scale-Out Backup Repository".

Now the link I kept https://go.veeam.com/v10 takes me to page about version 9.5. And the VeeamOn 2017 feature anouncements for version 10 have been edited to remove references to that particular functionality.

If Univirt hadn't posted a copy of the information at https://univirt.wordpress.com/2017/05/2 ... to-expect/, I would think I had dreamed the announcement and that I was going crazy

What's going on guys? Will I ever be able to use Azure Blob storage to hold Veeam backup files? And if so, when?

The current Veeam Azure solution requires an Azure VM with expensive Azure disks. We need that Archive tier.

Finally, please be upfront about changes in planned features. Just vanishing all references to functionality which had already been announced, without advising either a new timeframe or that the functionality will not now be delivered, treats your customers like fools.

Over to you.

[mongie]

I understand its coming in the next release (9.5 Update 4). I believe I was told that was due in the first half of 2018.

Strangely, they announced V10, then decided to switch to a more frequent release cycle which has been realised via "updates" to 9.5. Surely it would be sensible to just rename one of these point releases to "V10" and continue from there.

[Mike Resseler]

Hi Getontoit99, Mongie,

It is true that things have changed (and we believe for the good ) since that announcement. We announced around 5 major features for v10, but in the meantime, we have already released a few of those in update 3. Moving to that more frequent release cycle and adding new functionality (that is ready) into these updates gives you faster access to wanted technology and us advantages such as not needing to wait to release finished stuff and making it more mature faster.

None of the items announced have disappeared at this point in time and are in the works. (And others, not yet announced ones also ). What functionality will arrive in the next update (#4) is not decided yet. And whether we will have a v10 or it will be named differently is also something we don't know yet. I personally don't care about the naming convention (although I want something that is rather easy to understand ) as long as functionality keeps arriving.

Makes sense? Happy to hear your feedback

Mike

[Gostev]

Now the link I kept https://go.veeam.com/v10 takes me to page about version 9.5. And the VeeamOn 2017 feature anouncements for version 10 have been edited to remove references to that particular functionality.

I don't believe https://go.veeam.com/v10 redirecting to 9.5 is an intended change. Just a few weeks ago, following this link was an awesome page explaining the path to v10, including v10 features already delivered (basically, what Mike has just explained in his post). I've asked product marketing what's up with that. Thanks for bringing this to our attention!

Surely it would be sensible to just rename one of these point releases to "V10" and continue from there.

We can't really do this until we deliver what we said we would in v10. We promised and we shall deliver!

[DDIT]

Importantly...will it be called Veeam 10 or Veeam X?

(and will it have a notch?)

[Gostev]

Still an open question actually, so all ideas are welcome! In general, we want to get rid of versions.

[SBarrett847]

Still an open question actually, so all ideas are welcome! In general, we want to get rid of versions.

Keep a Sensible Version distinction. I've dismissed products before, simply because the naming / versioning system made no sense (looking at you ShadowProtect).

If a new Customer can't tell at a glance what a name means or what version is the current version, that's a lost customer.

Resist needless form over functionality.

[rgreen83]

Still an open question actually, so all ideas are welcome! In general, we want to get rid of versions.

Why do you want to get rid of versions? Versioning has nothing to do with how fast you can release features nor how many features can be in one. Getting rid of waterfall development I get, and appreciate, but look at chrome - version 65 now with small frequent releases for many years now.

I can tell you from experience as an admin and not a developer that versioning is extremely important to us. If I want to effect a change or create a search etc. on a large number of systems the best way for me to do this effectively is to target a specific version, this used to be fairly simple as parsing the program name or file path which would usually include some versioning info. Recently this has become an increasingly time consuming thing to do as developers want to hide version numbers (there are no less version numbers on the dev side, they are just being hidden from users) and we are now having to parse build numbers out of ever changing registry keys, powershell commands, hell i've even a few times had to parse individual dll file build numbers. Something as simple as determining what version of windows 10 are in use and which need what updates and work with what programs is a nightmare, please do not do this, Microsoft could make this much easier with a Windows 10.1, 10.2 etc. We do not just want your github edits flowing out to our systems with no way of knowing what is coming our way, and how exactly do you plan to have proper up-to-date documentation ready for releases? How will a VMCE know that their skills are current without versions?

I want to be able to search my systems and know which are on Veeam 9 or 9.5 or 10 so I know which need updated and support which features at a glance. Why could 9.5u1 not have been 9.6? Or 9.5u2 = 9.7, 9.5u3 = 9.8? If I need to research an error I'm seeing it is much easier (much likelier to return more valuable results) to do an online search for "error xxxx veeam 9.8" or "error xxx veeam 10" than "error xxxx veeam 9.5 update 4" or "error xxx veeam 9.5.0.1536" because humans communicate a certain way and build and patch numbers are not it and natural language search algorithms are tuned to how humans communicate. When a non technical client calls and wants to know why their laptop stopped vaulting to our CloudConnect repo I don't want to have to ask them to go into the registry to verify they are on the right build number or run a series of commands at the cmd line.

I would propose a very simple system, major.minor.patch versioning. Major versions for significant advancement, large breaking changes, and end of support, like this version of CloudConnect no longer supports that version of client at all, or version 8 no longer supported after this date. Minor versions for adding features and smaller breaking changes, usually forward breakage, like you must have this version of CloudConnect to support this version of client. Patch versions for no features, bugfix and security fixes only, breakage not expected. This should allow an even greater degree of flexibility for releasing updates for zero day flaws and security issues than you currently have as you are currently establishing that patches should contain major new functionality which you can only have ready once or twice a year.

[voyager529]

Hello Gostev!

In the genuinely nicest, most sincerely respectful, and unwaveringly gratitude-filled manner which can possibly be conveyed through a forum post...please read rgreen83's post repeatedly until the "no more version numbers" idea ends up in the dumpster out back.

The idea that version numbers are passé is the result of letting marketing run the show. Everyone running on the latest release is not going to happen. There will always be someone like me around who has specific requirements, and if at any point depreciating compatibility or API calls is planned, there will always be someone who needs whatever it is you depreciated. As always this has been described by the folks over at XKCD: https://xkcd.com/1172/.

But don't take it from me. Spend an hour or three with the tier one support reps and ask them how many issues are identified by knowing what version number the person is on. I guarantee you that it is a massive help.

"But Voyager, the solution is simple: we only support the most recent release. If users don't update, we can't provide support, so that can be solved with the 'check for updates' command; users can call back when it says 'no updates available'." Alright, fine. That goes back to the depreciating compatibility issues. Either remaining compatible with everything will be an albatross, or there will be users who are happy to remain on older releases to retain their needed compatibility. If given a choice between "upgrade your production software" and "use a different backup software", one of those is far easier than the other. It's not a threat, it's just a reality. Backups are the sort of thing that can be messed with during the business day. Production systems are not.

"But Voyager, all the Veeam systems you deal with are Server 2012 or newer, or VMWare 6.0 or newer, both of which will be supported by Veeam well into the next decade. Why are you so worried about something that is very unlikely to impact you?" Because agile development and constant updating keeps making a foundational assumption: what's newer is more desirable than what is already in place. If this was universally true, sites like oldversion.com and oldapps.com wouldn't exist. Windows Updates have caused more problems than they've solved, have not added a single useful feature since the RTM release, and have wasted millennia of man hours installing and breaking. Oracle keeps updating the JVM for Windows, but all I have gotten with every release is a "security change" that just makes it progressively more difficult to manage my JetDirect cards and iDRAC interfaces, the only two things in my environments that still use it. Agile development is a mindset that end users didn't ask for. The rest of us want stability, the ability to schedule maintenance windows, and to know that we won't have to choose between 'support' and 'a stable environment'.

"But Voyager! We're not an OS, we've got a perfect update system in place, our support reps are ready to do their magic every time, and we don't let the UX department rearrange things when they feel like it! You can trust us on this one, you'll never have the issues you've experienced with everyone else, because we thought of everything you're worried about and won't be removing version numbers until our system avoids every problem you've had!" I'll believe it when I see it.

Okay, I'm done with my rant because I've got issues to fix. Thanks for reading.

-V5

[Gostev]

Hello, Joey! Actually, build numbers address the points you have raised... and they are there to stay just because they are technically impossible to get rid of

My comment and question was about product versions specifically, the way they are today:

- Do we keep doing what we did before post-v10, naming releases like 10.1, 10.5 using our best judgement to decide how to call this or that version? Not only this is a waste of time to come up with every time (and people will always complain the release was too major or too minor for the assigned version number) - but most importantly, having these really slows down the communication. Because 99% of people who ask questions about some functionality or issue only call out this version number, when what usually matters is full build number. Actually, the same issue with vSphere - they tell me they're using vSphere 6.5, but there are 1.5 years of update releases in this vSphere version... and everyone knows that vSphere 6.5 of 2016 is so different from vSphere 6.5 of 2018.

- Do we switch to years, like the majority of software gorillas are doing? For example, Veeam Backup & Replication 2020. The small benefit over the existing approach is saving time from not having to come up with version numbers, and then defending ones later from folks who feel it's wrong or unfair. But the drawback is added confusion when you have more than 1 release per year - you still have to refer to build numbers in this case.

- Or do we do something special that you always wish software vendors did, but few or no one does? This is the kind of feedback I am looking for here.

For example, Ryan mentioned how Google Chrome approach can be a valid one - the comment I really wanted to hear, because I too like their approach a lot. Naturally, it is the closest to my "ideal" release naming, which is build numbers - except you don't have to remember all the build number digits, because the "major version" number is unique for every build that becomes generally available. So effectively, they roll with shortened build numbers.

And because they increment the "major" version number every release no matter how small the release is - this automatically ends every possible argument about actual majority of the given release. This number simply does not translate into one and doesn't represent one, period!

Also, because their "major" versions started to increment so fast, people quickly stopped using those when talking about Google Chrome (while still saying "Internet Explorer 10" for example). Which is how I'd love to see Veeam products referred to as well. The only place where you see Google Chrome version now is in 3rd party system requirements type of documents - or in issue descriptions when certain release breaks something.

Last but not least, I believe this approach maps very well to some update shipping process changes that our R&D would very much like to implement sooner rather than later.

[rnelson0]

Gostev,

I understand the desire to move away from version numbers, but I think it has more to do with your current version numbering strategy. You can move away from monolithic version numbering with updates (9.5, 9.5U1, 9.5U2, 9.5U3, etc.) and look to Semantic Versioning (semver) which - if, say, you had switched to it when 9.5 was released - would instead give you 9.5.0, 9.6.0 (9.5U1), 9.7.0 (U2), 9.8.0 (U3), etc. It of course can be interpreted many ways, but the major version (9) is associated with backwards compatibility, which only increases when you "break" something on purpose. The minor number (5) is for new functionality that is backwards compatible, roughly equivalent to your Updates. The final number is the patch (0) and can increment independently of the others. If you find a bug right now that only affects 9.5U2, does it get fixed in 9.5U4, or is there a hotfix to 9.5U2, and how do I as a user tell? Semver answers that - 9.7.1 - and allows for more patching between Updates (something I am not aware of Veeam doing outside of hotfixes directly from support). It's a lot easier for users to tell that 9.7.1 is the fix you need for 9.7.0 than a list of build numbers that have to be tracked to Updates in a KB article or forum post, or by engaging support if there's a special hotfix you got and it's not in the chart (granted, you already do a LOT better on this than some other companies but it's still a pain).

In the long run, this might mean version 9 exists for a long time before you bump to 10 when you start dropping support for older features/supported systems, but still provides a well known versioning system.

I'm not particularly opinionated on your versioning scheme, but semver gets my vote cause it's easy for users to understand.

The only thing I do NOT recommend is going to year-based versioning and use semver, like 2018.1.0. That looks good now, but in December you could put out 2018.12.0 and when it needs patched in January, is it 2018.12.1, or 2019.13.0, and if the later, did it break backwards compat? If you go that route, please at least don't make it look like semver

[rgreen83]

Thank you for your reply Gostev, I can see your perspective a bit better now. Whew, I kinda went tunnel vision when i heard "doing away with versions" lol. I'd be fine with a Chrome versioning scheme, even if, like Chrome, the versions aren't really referred to on the product marketing/websites/etc. Just be nice to us service providers and don't make every release breaking for our customers

Two things to keep in mind when considering going to that model though.
1. Customers will come to expect frequent or at least regular releases, regardless if there are major features, quarterly at least. I expect there isn't much point in making this change unless this is your intention, so I doubt this will be an issue.
2. Everyone will expect to be eligible for the latest release if they are paying, e.g. no more perpetual licenses for version 9 and all upgrades and patches to version 9, since there would in effect be no versions anymore. Again I know you've thought of this and likely already worked out the solution ( I would assume SaaS becomes the only model) but it will affect some folks and cause some grumbling so it's worth mentioning.

Lastly, like you mentioned about vmware's insane versioning, just please no, nothing like them. "6.5 update 1 patch g build 6.5.0.15000 build 8024368" is literally the version I had to track down to update vcenters today, smh.

[ITP-Stan]

@Gostev:
But how can you apply the licensing rules if you have no major versions any more?

If you bought Veeam v9 some years ago and did not purchase maintenance you can install install Veeam B&R v9.5U3 but not v10 when it will come out.
And yes, in an ideal world everyone just pays for maintenance, but that's not the case.

You can still apply those rules if you switch to semver (i.e. veeam B&R 9.8.0)

However I don't see how you will apply those rules with Chrome like versioning i.e. Veeam B&R 65

[tommyo]

I don't really care what you call it. What's frustrating to me is the promised updates and functionality haven't been released yet.

I was at VeeamON 2017 and heard over and over again about the new features that would be available in version 10 that were supposed to be released end of 2017 or early 2018. Some features have arrived, some haven't.

Don't get me wrong, I'm a big fan of the Veeam products and consider them essential to our success. I wouldn't want Veeam to rush anything to market before its ready but it is frustrating to hear the announcements and then to have to wait longer than expected.

[yasuda]

A long time ago, I worked at a software company where one product's version numbers were actually useful. I think it was that the major number indicated database version compatibility, i.e. all sub-versions of the major version were compatible with the given database version, and you were safe to upgrade without needing to upgrade the database. The first sub-version might have indicated API compatibility. But what always seems to happen is Marketing takes over version names, and you wind up with Windows 10 and there was no 9.

So I'm fine with just using build numbers.

[aich365]

Have just been checking the EOL schedule and can see that version 9.0 is EOL in Jan 2019 so an opportunity to upgrade customers

In previous years the convention for software releases was:
Major upgrades with new features (and some fixes) had a new version number e.g. version 3 to version 4
Interim releases were of the form 3.5
Minor releases were of the form 3.5.x

Customers have been used to this.
E.g. from Windows 7 they expect to pay for Windows 8 but not for Windows 7 SP1

To get customers to upgrade and pay their support company for the pleasure of new functionality is a much easier sell if there is a version number change
So if the next release is named Veeam 10 they can see at a glance that this contains new functionality and is a major release so it becomes a much easier sell.
If it is just named Veeam 9.4 customers will believe it only contains fixes so should be covered under maintenance

Getting customers to pay for the time taken to upgrade when there is only a software version suffix change is a much harder sell

Thanks

[Gostev]

Yes, totally agree. Post v10, we're planning to start following Google Chrome model of incrementing major version with every significant release (which we typically do twice a year).

[ITP-Stan]

And how will the licensing affect this new major release schedule?
Now customers who did not renew their support but had a valid license for 9.x, could still install 9.5U3. Only when release 10.x comes out they can no longer update.
But when you plan to switch major releases every 6 months, this means that 6 months after support expires you can no longer update without buying new licenses or paying for backdated support.

I know in an ideal world everyone should just make sure that they pay for support. But I'd like to know for those very small corner cases.

[Gostev]

OK, probably I should not have said "2 major releases per year", as one is usually a smaller like Update 3a was. While it does have more features than our major releases back in early days but overall, these are mostly focused on platform support, minor improvements and bug fix. May be we keep calling these a/b/c releases or something, to imply a relative "minorness" of the update - this is still a topic open for discussion.

The general direction is indeed to [eventually] not allow updates for customers without active maintenance agreement in force, which is the industry-standard practice. Actually, we already have a warning popup since Update 3a for all customers who are downloading this update without active maintenance agreement in force, saying that soon they will no longer be able to do this. Legally speaking, they are not eligible even today.

[csydas]

How is this going to be enforced exactly, since the installer doesn't seem to really care about much of anything during the install process (it's happy to continue without a license). Peeking at my license file, I can see that it has a line regarding "version = 9.x" -- is versioning going to be hard-coded into the license file with v10?

[Gostev]

Yes, just like with all the previous versions. Until v9, we used to release a major release every year, and each such release required a new license file with the matching product version.

[JONO]

Just checking the date onthis post was from March 2018 ? When is version 10 available ?

[nielsengelen]

It will be available later this year.

[aich365]

From Gostev's blog this week

The RTM build for Update 4b for Veeam Backup & Replication 9.5 was shipped early last week
If nothing unexpected pops up (especially around 3rd party platform updates), Update 4b should hopefully be the last version 9.5 build. Our next planned release vehicle is v10, which goes into the private beta later this month, and is expected to be shipped before the end of this year.

[CBPower]

I would be happy to beta test 10. I really need the cifs backup ability so I can get rid of previous backup appliances.

[wishr]

Hi Dennis,

Welcome to Veeam Community Forums and glad to see your interest in v10 capabilities.

Please, reach out to your local Veeam sales representative to see if they can provide you with the access to private beta.

Thanks