Versioned Default Values

[lcreid]

I'd like to explore the idea of versioned default values, similar to, but not necessarily the same as, Rails' versioned default values. The goal is to allow us to introduce breaking changes that developers could opt-in to.

[I'm going to work on a few draft PRs to illustrate what I'm thinking, but if you want to comment on these hand-wavy ideas, I'm all ears.]

Historically, bootstrap_form's major version tracks the major version of Bootstrap that it works with. If we're following semantic versioning, we can't introduce any breaking changes until Bootstrap changes. But that is infrequent, and really limits our ability to improve bootstrap_form. By having a way for developers to choose their defaults, we can improve the gem for those who opt-in, but we wouldn't break existing apps.

What might these versioned defaults look like? Here are some examples:

• Currently, the div that wraps most controls (that originated with Bootstrap 4's .form-group) has an mb-3 added to it. We could allow developers to chose to use a different class, or none at all, for this div.
• Changes in behaviour: For example, does specifying a class on a control completely override the default class, or does it add to the list of classes?
• Changes in implementation: If we were to do extensive refactoring or other code changes we consider risky, we could introduce a default that would act something like a feature flag. Developers could opt in to the new implementation, and easily opt out if they discovered problems (and hopefully report the problem).

Having worked in some code bases that had many feature flags, I'm aware that this could lead us to a bit of a mess if we don't keep the number of options to a minimum. I think the ability to improve the gem is worth the effort of managing different options.

More details:

• Not all versions of bootstrap_form would have new defaults. Typically, we'd introduce new defaults when there are breaking changes, or when we introduce a new default. Keeping the number of variations to a minimum is key.
• The end programmer would define their default version. If they don't define a default version, bootstrap_form would use the oldest version we currently support.
• We would stop supporting a version (of defaults) after a reasonable deprecation period (at least a year) for any breaking changes.
• The versioned defaults would only apply to the current major version of bootstrap_form, and therefore the major version of Bootstrap.
• We typically issue deprecation messages for the old behaviour, if we intend to change the default in the future.

[lcreid]

As I start to actually implement this, I question whether we need to tie the defaults to a version, the way Rails does. Thinking of this simply as a way to configure the gem is simpler. I don't think we lose any capability by treating this as configuration rather than versioning. We can still have options that go away eventually (probably with deprecation warnings).