Explicitely added the default value also to views in com_contact, com_banners and com_categories and to the edit forms.
This doesn't change any functionality but is good for code consistency.

How about we set it by default 'on' for updating users?

The only way to enable it for updating users would be to use the SQL files and set the parameter there for the supporting extensions.

Setting the default values to 1 will create issues with extensions that don't support versioning.
That is because the setting is also checked in two shared JLayouts and in the JTableObserverContenthistory itself.

Why do you have to set it for all extensions? As these parameters are unique to each extension why can't we turn it on at least for the core extensions?

That's what we do now and which fails :)

Currently as long as the extension options aren't saved, the default values in the code are used. That means that the view will think versioning is enabled (default value 1) and show what is needed for it (leaving users to think it's enabled). However since the observer thinks it is disabled (default value 0), nothing will be saved in the history table.
Also extensions using the JLayout (joomla/edit/details) don't show the version_note field as it defaults to 0 as well.

It may be possible to find a solution to enable the feature by default. I think the observer will not be a big issue as extensions have to actively map it when they support versioning. The layout will be the bigger problem to solve.

Personally I think we're safer (and for sure it's easier) to have this feature disabled by default for updating users and let the user enable it if he wants to use it.

So I'm still confused - if we set the necessary parameters in the update sql files then we're all good right? The parameters are set up as is necessary and everything will work as it's supposed to?

Yes, if we set the parameter in the update SQL or with a script, all will be fine. Doesn't eveb matter if we enable or disable it there.

Personally I would still set the default values to 0 but it would then be purely cosmetic and a guide for 3rd party developers.

If you set the default behavior as enabled in library files and the base layouts, then extensions have to explicitly disable it if they don't support the code or there will be other issues for them. Mark took the conservative approach and made it so that you would have to explicitly enable the code to use it, which also allows developers to not be affected by that change. So that's why we should default disabled in at least the PHP side of things.

It's possible to update the user's params to enable on update, but we typically don't touch those. There are 2 notable exceptions to that though: in 2.5.0 when we moved where the filter options were stored and for 3.2.0 with the template manager and CodeMirror updates. Those were out of necessity, not convenience like this situation would be.

A part of me says to close this PR and leave the defaults as they are (well, get them consistent in the enabled direction if they aren't) and have some clear documentation about needing to go in and save your component params on update to enable the feature.

@mbabker This PR only deals with setting the default values consistently to be disabled. So it's clear to the user that the feature is not enabled. Currently it looks like versioning is enabled because the fields are there, but in fact it's disabled because the functionality is turned off in the observer.

The discussion got a bit misleading. I agree with you that we should not touch the parameters on an update if not neeeded. Documentation is always a good thing of course, another use for com_postinstall?