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.
Personally, I’ve never found any of the issues post-7.0.1 to be anything more than minor annoyances. Certainly not something that prevented me from working.
I’m pretty OK with Steinberg’s update schedule. Sure, it’s not like Reaper that gets updated almost weekly, but it’s not AppIe either, getting updates twice per decade…
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.
Are you saying there are new updates to Cubase?
I haven’t heard anything about it!!!
Just joking of course suntower but when I think about what you posted.
Is this even technically possible?
Are there any developers/companies of major apps
capable of doing updates once a week.
I’m not a coder but I would imagine that working on a project as ‘dense’ as Cubase
with all its lines of code would take mucho time to change anything.
In the past we users have ‘railed’ at Steiny to be more open with us,
talk to us more on the forums, give us more updates.
IMHO
they have in recent years done all that. And I for one applaud them and
hope they continue in this current direction.
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…
That is pretty much exactly the opposite of current engineering best practice. What you are describing is what everyone of -my- generation (old farts) did.
