What if paid x.5 releases were for simple, menial, professional use improvements,
And then #.0 full releases had new features and were released when absolutely ready.
I’m feeling a little agitated at the moment with new features being half-integrated/buggy, and old needed improvements/requests never coming to fruition year after year.
As I described it in that thread: The end result user experience is, feeling like swimming in a bowl of chunky cold beta soup and old left behind features - lots of chunky features… that are difficult to bite into, and some of the chunks are years old.
There’s just something that feels off about the development cycle and quality. It takes years to get very simple but important changes.
No. Having the X.5 releases be paid caused a ton of confusion in the past. Besides ultimately the name/number of a release is only a cosmetic difference. Personally I prefer counting by ones and not halves.
Ultimately, it is the philosophy of what makes it into a release, how releases are regression and acceptance tested, and the completeness of working features that matter.
How this gets “wrapped” into paid/unpaid or full-version/update-version numbering is largely irrelevant.
While I have been critical of what appears obvious holes in regression and acceptance testing over the years, a mostly cosmetic change, with additional opportunities to charge end users does not appear to me as a solution.
The numbering system and the pricing are separate issues. Most of the software world doesn’t require money having to be paid for x.y releases.
In my (subjective) reading, Steinberg’s detour into that x.5 paid update thing for a few years was an (arguably cheesy) attempt to make it more palatable to charge money annually rather than the longer term cycles they had before in addition to introducing the concept of having to pay more when skipping previous paid updates.
I’m not a fan of such mental gymnastics around business models, but then again, I’m no longer in the software making business. If obfuscation of pricing models is the only way to keep a company afloat, because that’s what customers want (or fall for), then so be it. We live in an increasingly weird world in many more ways than just this. And that current world is not only difficult for us customers, but also difficult for software makers.
I fully expect Cubase releases to be annual with full x.0 numbers plus higher pricing for “skipped” paid releases from now on. For long term continuous users it’s becoming more similar to a subscription model, but you get to keep using older versions if so desired (assuming there’s no retirement of the current software activation servers/scheme).
Absolutely not , there is enough backlash over the current system already which built on the antique premise of having a perpetual license mixed with ‘if you don’t upgrade now, next year we charge you double’, having to pay for x.5 releases will only agitate some users further.
From what I observe the underlying problem is that the feedback loop isn’t fully closed, which causes a sentiment of ‘they release half baked features’ and ‘they don’t listen to us’. However, Steinberg does listen to community requests, as evident by for example the prompt integration of summing folders on my c15 update video this year or the prompt integration of volume sliders in the track header following Alice Byno’s c14 update video.
The equation is simple: if updates are well worth the price, we would gladly pay the price.
What makes you think Steinberg is implementing half baked new features because they’re not being paid enough? And how rewarding such mediocrity by willing to pay for x.5 updates will improve things?
I was a supporter when they changed the relesae cadence. Now I am not so sure. I don’t know what the solution is, there are several different models but hard to say what would work best.
I do think that Cubase/Nuendo has more to lose by letting bugs build up, than offering new features. The risk is losing long-time customers who are/were avid supporters of Cubase.
And without a serious ‘stable’ version, you can’t just stay on the previous years version, although I think there are a lot of pros that stayed with C12.
Guys. Dorico is a serious Software development company and as such has rules.
Dorico (in my eyes uses the IBM Standard of “VRMF”. Version, Release, Modification, Fix.
So
“V” is 1, 2, 3, 4, 5, 6 i.e. major, over all changes.
“R” is release - this normally increments when internal DataBase constructs need changing,
“M”, modifications when how things operate need to be changed
“F”, when code needs to be fixed without changing “RM”
I’m currently running Version 6.2.30.6245
(or Version 6. Release 2. Modification 30, Fix 6245)
Now you can understand the numbers.
, there is enough backlash over the current system already which built on the antique premise of having a perpetual license mixed with ‘if you don’t upgrade now, next year we charge you double’, having to pay for x.5 releases will only agitate some users further.