TaoJones
Beyond Driven
I see your point; however, high level release notes (anything for public consumption) wouldn't be phrased in such a way that would describe fault or blame. Instead, see as an example the most recent iOS app release - the release notes simply reference minor bug fixes and performance enhancements (I'm paraphrasing). While some might say there's no value there, I disagree. By specifying what something is, by default it specifies what it is not - in other words, it isn't something major.Wouldn't that mean that Tesla will have to admit fixing something that got screwed up in a previous release? Like the recent shuddering, the P85Ds dying spontaneously after Tesla screwed up the range mode function shortly after launch, etc. This could get hairy.
In the context of *.58, clearly it's not a release that includes lanekeeping. While people in the biz know that point/dot releases are by definition more minor than, say, some variant of the next number up (e.g., 7.x.x), many non-technical people don't know this.All I'm saying is that providing standard release notes removes a lot of uncertainty and in some cases, risk. The notes don't have to be detailed.
Per your examples, one release might reference "minor TACC enhancements". Let's say that was the release that introduced shuddering at low speed. The next release to fix that might also reference "minor TACC enhancements". Point being that we wouldn't look for changes in some other system. No blame or acknowledgement would be conveyed through the release notes in any case.This isn't the most succinct reply now that I look at it - apologies, in the words of Sam Clemons, for not having the time at the moment to write a shorter missive.
Last edited: