Interesting topic. I disagree that this release is too early for public release based on the following:
I make a difference between two releases in terms of what can be expected from it.
FIrst thing is that before they release a new version with new functionalities, they finish (to a certain level, but quite high) the previous release. That is 7.5, and that version is under any condition available on the system since licenses are working top-down. The mature version should imho be the version to be used in live or in pro surroundings.
At the same time there is an anual pressure to release new functionalities on time. (look back on how many questions there were for a new release at the end of 2014) And what follows is an x.0 release on schedule. It has been tested since august 2014 by a team of beta testers. (not me)
Debugging this completely with use cases like is being done in a professional environment is virtually impossible, since documenting this would take up thousands and thousands of use cases. No single company has that kind of resources available. And releasing it to a bunch of normal users as beta testers without having the proper feedback line setup is also not an option since the guys who do the programming are most of the times not end-users themselves and beta testing without a proper schedule and documentation is very inefficient.
It could be an option if improving the testcycle would be a requirement, to do a release to a “wider” user base before doing the final public release for some months. But that is on the other hand a killer for the release schedule that in fact is quite strict nowadays. (every year something new) So they do a release, imho, that is functional, based on a certain amount of use cases, and then it’s release time.
A release is premature if there are still critical malfunctions. If that is still present in a release, that is a bad. Generic things like crashes, blue screens, startup problems, and other unwanted severe bugs may not be present in an x.0 release. I think with version 8.0 there were no real critical bugs. The biggest i was aware of were the incompabilities on windows systems with Always on top and the new GUI. That was quite severe in my opinion, but that was also fixed quite fast in a 8.05 release. (but they were windows only (and tells something about what kind of machines the beta-testers are using))
Bugs that are critical under user-specific conditions are not crititcal in a generic way, and if they are traced before the release date is thus heavily dependend on the fact that the guys who design the use cases for beta-testing are aware of them and if they were listed as a possible use case.
Best thing to do with those bugs that are still there is to get them documented as quick as possible, so that the program can be finetuned.
So for me: version 7.5 does its job and everything i need is recorded and present in 7.5 and needs no change. That’s fine.
At the same time i am working a lot in the new version 8, bugs included, and i’m using this “free” time to adapting myself to the new workflow that has been introduced. For me it will take several months before everything is fully setup, but hey: i give version 8 a big 10 in terms of new workflow and new functionalities. I will be able to do a lot more with just the same equipment, and that’s a good thing.
Once this release is going to it’s mature state (probably before the end of this year), i’m going to have one hell of a good DAW with excellent workflow.
Meanwhile, 7.5 will do “the job”.
FWIW,
kind regards,
R.