chickensevil
Active Member
Why?
i would actually like them to take the opposite route.
Tesla sometimes claim they want to be a game changer. Then why not be that completely? Publicize the sw plans. Target dates, target features etc. Then as the plans change, communicate the changes.
this can be extended to even more things. Publicly communicate production figures in real time, model x and 3 dev progress, etc, etc. THAT would make them a real game changer...
You guys have apparently never played an MMO... There is an interesting dynamic and fine line between how much information you can and should give out before a release is made. This is basically like an MMO for the update releases (Heck I am sure some day they will release an update that you will have to pay for the expansion pack... I.e a new car... In order to use those particular features). That being said, the fastest development time is releasing big updates all at once vs small updates in a shorter interval. The reason that's true is the amount of separate working versions you have to maintain. If they made their version numbering more clear then it would make a bit more sense... But basically the major releases should have all the good stuff. When they are done with that package it should be pushed out through the appropriate QC chains, testing, etc... As soon as they push out for testing to the core design team has already moved on and is working on the next update. So let's say version 1 is in testing, the Dev team is now cracking away at version 2. Any changes made to version 1 they have to duplicate that change into version 2 at the same time... This makes it the simplest for hot fixes and patches...
Contrast that with a rapid release cycle of every month... Let's say you have a Dev time for a new feature of one month an internal test time of one month, an alpha (friends and family) test of one month, a beta of one month, and then it goes gold. By the time the product goes gold the core Dev team would actually be 5 versions ahead... This means when a critical problem is detected in any one of the previous 4 versions they have to stop everything and roll those fixes forward... This hurts the amount of time they get to focus on new stuff because they have to spend so much time rolling hot fixes forward.
At least that has been my experience with dealing with it. Right this moment the Dev team is dealing with AT LEAST three different versions... 5.12, 6.0, and 6.1. A critical bug detected in 5.12 would have to be hotfixed into 5.13... Think fire issue with the suspension change.... That would be a critical hotfix. Now you might have to roll that change forward across two working versions and that takes time... How much time depends on the complexity of the fix and how much it interferes with NEW code that you are working on implementing.
So no... I don't think they should speed up the release cycle. I think they should slow it down... 6 month cycles should be more than fast enough. Which... If you have been keeping tabs, 5.9 came out with a bunch of cool features around March... This release is coming in Sept... So we are looking a major updates in that cycling... They should be fine keeping it that way. If you want MORE features slipped in there they will need more people... Given the nature of these updates not really costing us anything (where ARE they getting funding for this?) I don't know how much you can expect them to do.