Move Float fields to contrib

Removing the upgrade path tag because I think we can do this without an actual update - just a module for sites to add from contrib if they use the field.

When updating the issue summary, I forgot we don't have 📌 Create a way to declare a plugin as deprecated Needs work yet. Also if we only deprecate the plugin, it will still be in the UI for all Drupal 11 sites.

So it might be better to go the module route in core after all, this would look like:

1. Move the plugin and any test coverage to a new 'Float field' module.

2. Add an upgrade path, in system module, to install the module on any site that's using the float field.

3. Immediately/asap mark that module deprecated and do the other steps to move it to a contrib module.

I went through different contrib use cases for floats and I didn't really find good examples where float would be used correctly as a bundle field. There are examples of valid use cases where float is used as a base field. This doesn't mean someone couldn't be using it for the right reasons as a bundle field but by nature float is probably something that would be more likely to be used as base field for use cases like computations.

If float field type is a minimal maintenance feature for us, I'm wondering if we should keep float as a field type in core but start by marking it as no_ui: true? A contrib module could be then be added to add it to the Field UI for those that need it there.

I like the no_ui idea!

Let's try no_ui here. The main issue is the UX issue presenting these as choices in the field UI, saves us having to do the full module and deprecation route and doesn't prevent us from doing that later if there's a new reason to.

Removing the product review tag based on #38. Removing the subsystem maintainer review tag since removing the field type from UI is much less invasive than moving it to contrib.

Pushed a two-line MR to see what breaks, if anything.

lol, two more lines necessary to get things green, so four lines in total.

That's a lot easier than factoring out to a module and moving to contrib!

Very nice - I think with the addition of a CR we are good to go here.

Added a change record and updated the issue summary.

Perfect.

Committed b23f427 and pushed to 11.x. Thanks!

I agree that this is a very rarely used feature, but it is sometimes used, http://codcontrib.hank.vps-private.net/search?text=field_type%3A%20float... has 3 pages of results (quite a lot are just tests). default config of course still works, just linked to that for use cases.

Unlike an optional module that non-developers can install, the no_ui flag requires that you implement an alter hook to be able to still add them through the UI.

As a compromise, I added an untested example hook to revert this, if someone creates a module for doing that they can share it there.

Not mentioned here but we discussed on Slack that it would be simple to create a module for this. We could add that to the CR in case that someone wants to create that.

Automatically closed - issue fixed for 2 weeks with no activity.