Change:
import { IInstantiationService } from 'vs/platform/instantiation/common/instantiation'; import { IBackupModelService } from 'vs/workbench/services/backup/common/backup'; import { IMessageService } from 'vs/platform/message/common/message'; <ins> import { IStorageService, StorageScope } from 'vs/platform/storage/common/storage'; </ins> export class TextFileService extends AbstractTextFileService {

Discussion:
We enabled hot exit by default to get more coverage from insiders. We need to think about wether we should leave it on by default for stable.
My concern having this on by default for all save settings is as follows: user uses manual save exists VS Code 1.8 with dirty files. Now we will not prompt him for save anymore. he goes to a terminal and does git commit, git push which will not push all his changes. the new behavior might look like data loss to him. In fact we are breaking / changing their existing workflow and I think we shouldn't do this without letting them know. suggested that instead of only showing the save dialog on exit in the scenario we can enhance the dialog to let the user know that we now support hot exit and whether he wants to enable / disable it. I like that idea.
is right. I personally think enabling hot-exit by default could cause more problems than it would save. People are not necessarily used to use hot-exit. In order to get more coverage, a notification could popup after the 1.8 installation asking the user if he/she wants to enable hot-exit.
To answer such a question I think it's best to look at the competition. Sublime, Atom and Notepad++ which are arguably the most similar applications to VS Code all have hot exit enabled by default and are generally praised for it. The fear of looking like data loss was something that was considered when designing the feature and that's why it's currently restricted only to reloads and application exits, not arbitrary window closes. If hot exit was triggered, all backups will be visible when next launched.
careful though, we have not had hot exit from the beginning and just adding it by default without informing the user asks for confusion. Those other tools likely had it right from the beginning or actually did not care. I still think that educating the user towards this option is a good way of solving this. E.g. during shutdown with dirty files, instead of just quitting without prompting, tell the user about hot exit. I think this would have to be a modal dialog as well though.
Educating is good, imo the default should be what most prefer though and the educating should go the other way (informing users this is the new default).

Currently the discussion seems to be based on a theoretical class of users that will be confused about data loss when the editor closes and not open it again (when a restore would be obvious). It is certainly not a new concept that would take long to grasp though as most other "lightweight editors" have it enabled by default.
I believe something simple as a one-time modal dialog on quit (if there are dirty files) would be great for people to learn about this change. This dialog could include a button to open our documentation around the feature where we can go into more detail about how this feature can be configured and what it means.
Is there a middle ground where we enable it for all new users by default (like the theme change we did where new users got dark+, existing users stuck with dark) and notify existing users how easy it is to turn on (with the message as suggested). That way we don't make a change for existing users, but new users looking for it just get it - which is what they probably expect. For existing users we 'promote it' so they adopt it.
I'm in favour of keeping the current behaviour and show some documentation, like suggests. But I'd take one step back and explain the overall picture. Over here in Zürich everyone agrees that the best possible configuration is using auto save, which removes the need for hot exit. So why don't we mention that as well? I'd like to see simple, straightforward docs on the three possible setups: VSCode style, with auto save; Sublime style with hot exit; Notepad style with nothing. This would lead to a better understanding IMO.
FYI hot exit is still useful when you have auto save as it works on untitled files.
Tough call. I like approach to avoid 'breaking' existing users. The broader issue is what 'flavor' we want to have by default. I'm leaning towards having less dialogs and would enable hot-exit (and auto-save, if that was on the table) by default. Ultimately we'd have to ask our users what they prefer. Have we received much feedback since this was enabled in the insiders build?

As I've bee annoyed by for untitled files, I would prefer that when I get a new version of VS Code and I attempt to close the window or an untitled file, it pops up a window telling me about hot exit feature that mentioned above. This way we can make sure anyone who doesn't like old behavior can adopt the new one when they run into the trouble again. The only concern in my mind about setting hot exit as default is that I may hit quit by mistake and if the window just closes silently, I might be scared somehow. It's not a big deal as ppl can still see their file next time Code is launched but there is some .
So it appears most people are thinking a modal something like this to appear the first time an exit with a dirty file is triggered: ! The Yes and No options would ensure the question is never asked again, while Cancel would cancel the exit and defer the decision to later. This would force a decision at the point in which hot exit would trigger first.
I propose to change the wording in the popup to use 'remember' rather than 'keep track' to make sure users have no problem understanding what this is about. Also, we should add subtext that tells users that they can change their decision later by modifying the settings. Otherwise, I think the dialog is good way to avoid user confusion.
Would after 'No' still be the dialog asking if I want to discard unsaved changes? If not: I'm missing a clear indication that 'No' will discard changes and in which files. But I guess you will just keep that second dialog, the two will show together at most once.
and I had a separate discussion about the options we have. We came back to the education point of view. I.e. we inform the user that hot exit is now by default without asking for a decision. This avoids any potential concern of data loss the user might have initially and keeps hot exit enabled.
We could do a message box like that either: a. The first time hot exit it triggered for all users b. The first time it's triggered for users who updated only c. The first time VS Code exits for all users d. The first time VS Code exits for users who updated only How is this for the modal dialog? Message: Hot exit enabled by default and will remember any unsaved changed between sessions.

Detail: You can disabled hot exit in the settings. Options: Ok
I would only show it when a user quits with dirty files and is a returning user (can we find that out?).
well we show a message box when an update is installed by the version in local storage, it's just a matter of whether it's persisted beyond that.
We only store the current version in the storage. We use the stored value to compare with the current version to know whether there was an update. But we don't store the fact that the user has had an update.
I would add something that explains hot exit a little more since it might not be clear. Something like: Message: Hot exit enabled by default and will remember any unsaved changes between sessions without saving them to the underlying files.
Had a chat with instead of going to the hassle of checking whether the was an update, I think we should just show the message for all users the first time and eventually remove the message when the majority of the users know about the switch. Probably in 1.10 or 1.11? That solves the problem of education without annoying people until the end of time when they set up a new instance of VS Code.
This is what I'm moving forward with, let me know what you think of the wording. ! I moved the majority of the message to the detail part of the dialog as the message part is really large and bold.
I've fixed the typo (unsaved changed) and ended up rephrasing it to:
Thanks