I just placed a suggestion to address the following… which is a complaint.
The 7.06 announcement is cool. But there’s just too much time between releases. I’d much rather see less adventurous feature/fix lists, but more releases. Perhaps 1 feature/fix per build—but one per week. I realise this would likely lead to weekly grouses about ‘WHY NOT MINE?’ but that seems like a small price to pay for faster turn-arounds.
Some of these fixes just shouldn’t have to wait 3-4 months to be added to a bundled .0x fix. There should be a mechanism for getting them out faster.
I don’t agree with OP. It has usually been around 1½ month between the updates, which I think is well balanced. This time it took an additional month due to vacation, which was expected. Very frequent updates would just create more work and speed down the overall update progress.
I don’t think any micro updates should be -required-. Most updater programs allow one to skip any number of minor updates until a fix comes along that you need.
But -fixes-… things like the font size in MixConsole or any of a number of nigglies that they keep changing with each .0x release a) shouldn’t happen in the first place and b) should be available quickly.
Making fixes more granular would give one the best of both worlds.
Of course it is. If you only make 1 change to a software… and you -know- it’s limited to one portion of the code, you can safely do a new build every -hour- if you want.
What makes for long release cycles is, in my experience (as a software developer of ‘mission critical’ stuff) is largely psychological.
You want to give the engineers enough time to do certain fixes. But if you take 3 months and just do ‘boring’ fixes, people get upset. So when you plan your schedule you try to make the fixes fast enough to make users feel taken care of, but you also want to include enough ‘features’ to make users ‘feel the love’.
Mozilla has done new builds every month. Microsoft has a Patch Tuesday every month. Lots of smaller projects go weekly.
The point is: if you make changes in a -granular- way, you get the fixes out the door faster. The key is to not mix ‘fixes’ with ‘features’ and try to have it both ways (as in the above).
I contend that C7 has been the worst .0x release in a looong time, simply because SB has been trying to mix fixes and features with each version. Each .0x isn’t so much ‘fixes’ as it is a ‘new coat of paint’. I’d like SB to do as MS does—separate feature releases (which are few and far between) away from =fixes= which happen often. This would reduce the number of regressions (2 steps forward 1 step back) that, IMO have plagued C7.
Well - Cubase is a complex program. A simple “fix” can have consequences in several area’s of the program. In complex programs even the simplest fix can have a LOT of work involved in area’s a user would not expect or think about. On top of that - Every simple “fix” has to be tested against a broad range of configurations on at least two operating systems to make sure it does not lead to instant desaster when applied.
If you take that in consideration it is contraproductive to do just one fix at a time. Better take a lot of fixes and start the test phase after that. A few people here are complaining they are “beta testers” for Cubase (far overblown in my perception), but if you want fast fixes without time to test them touroghly, you will become a REAL beta tester.
Yes programs like Reaper get updates faster, but do not forget Reaper is a far less complex program than Cubase, so its much more easy to manage. Wait until Reaper will become more complex (drastically increase features), and I guarantee you wil see the rate of fixes go down…