Version 4 roadmap

Since 4.x is the current version, perhaps that should also be the default version at https://git.drupalcode.org/project/computed_field/? (is now 3.x)

The link https://git.drupalcode.org/project/computed_field/-/blob/3.x/README.md under "Resources" could then also be updated to this:

<a href="https://git.drupalcode.org/project/computed_field/">README.md</a>

Good idea! Thanks -- done both.

Another observation: In Drupal 10, if you simply run composer require for this module, it grabs version 2.x. So it seems like Composer sees 2.x as the current default version for Drupal 10:

$ composer require drupal/computed_field
Using version ^2.0 for drupal/computed_field
./composer.json has been updated
Running composer update drupal/computed_field
Loading composer repositories with package information
Updating dependencies
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - drupal/computed_field dev-2.x requires drupal/core ^8 || ^9 -> found drupal/core[8.0.0-beta6, ..., 8.9.x-dev, 9.0.0-alpha1, ..., 9.5.x-dev] but the package is fixed to 10.0.3 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.
    - drupal/computed_field[2.0.0-alpha1, ..., 2.0.0] require drupal/core ~8.0 -> found drupal/core[8.0.0-beta6, ..., 8.9.x-dev] but the package is fixed to 10.0.3 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.
    - drupal/computed_field 2.x-dev is an alias of drupal/computed_field dev-2.x and thus requires it to be installed too.
    - Root composer.json requires drupal/computed_field ^2.0 -> satisfiable by drupal/computed_field[2.0.0-alpha1, ..., 2.x-dev (alias of dev-2.x)].

Running composer require drupal/computed_field:^4.0@alpha gives me the correct, current version.

I have no idea, sorry! Composer things like that totally confuse me. Can you try with a clean project that just has Drupal core from the template and nothing else?

Both 3 and 4 are unstable versions, until either gets a stable version, you’ll get 2 if your project doesn’t have root minimum-stability dev. Especially if v2 otherwise meets your site requirements (core compat, etc)

You’ll need to designate @alpha until stability increases.

Thanks @dpi, that was also my hunch. And after looking here, it looks like 2.0 was the last stable release, and why you get that by default:

$ composer show drupal/computed_field --all
name     : drupal/computed_field
descrip. : Provides a UI to add computed fields to entities.
keywords : 
versions : 4.0.x-dev, 4.0.0-alpha2, 4.0.0-alpha1, 3.x-dev, 3.0.0-alpha2, 3.0.0-alpha1, 2.x-dev, 2.0.0, 2.0.0-beta1, 2.0.0-alpha4, 2.0.0-alpha3, 2.0.0-alpha2, 2.0.0-alpha1, 1.x-dev, 1.0.0-alpha1, dev-4.0.x, dev-3.x, dev-2.x, dev-1.x
type     : drupal-module
license  : GNU General Public License v2.0 or later (GPL-2.0-or-later) (OSI approved) https://spdx.org/licenses/GPL-2.0-or-later.html#licenseText
homepage : https://www.drupal.org/project/computed_field
source   : [git] https://git.drupalcode.org/project/computed_field.git cc5d8de61219f99bf438ef4869cdd61728c58039
dist     : []  
names    : drupal/computed_field

support
source : https://git.drupalcode.org/project/computed_field

requires
drupal/core ^9 || ^10

My composer.json is already set to "minimum-stability": "dev", I thought that would be enough ... But now I see "prefer-stable": true, and changing it to false I now get 4.x:

$ composer require drupal/computed_field
Using version 4.0.x-dev for drupal/computed_field
./composer.json has been updated
Running composer update drupal/computed_field
Loading composer repositories with package information
Updating dependencies
Lock file operations: 1 install, 0 updates, 0 removals
  - Locking drupal/computed_field (dev-4.0.x cc5d8de)
Writing lock file
Installing dependencies from lock file (including require-dev)
Package operations: 1 install, 0 updates, 0 removals
  - Syncing drupal/computed_field (dev-4.0.x cc5d8de) into cache
  - Installing drupal/computed_field (dev-4.0.x cc5d8de): Cloning cc5d8de612 from cache
[...]

Quick update: Setting "prefer-stable": false, gives me dev-versions by default for any module, so you're correct @dpi, best to specify @alpha for now :)

$ composer require drupal/token
Using version 1.x-dev for drupal/token
./composer.json has been updated
Running composer update drupal/token
Loading composer repositories with package information
Updating dependencies
Lock file operations: 1 install, 0 updates, 0 removals
  - Locking drupal/token (dev-1.x bef22ec)
Writing lock file
Installing dependencies from lock file (including require-dev)
Package operations: 1 install, 0 updates, 0 removals
  - Syncing drupal/token (dev-1.x bef22ec) into cache
  - Installing drupal/token (dev-1.x bef22ec): Cloning bef22ecf09 from cache

I might not be understanding something.
What is the upgrade path for someone running v3, who upgrades Drupal 9 to Drupal 10, if "there is no upgrade path from v3 to v4" as stated on the project page? Am I reading that right?

> What is the upgrade path for someone running v3, who upgrades Drupal 9 to Drupal 10, if "there is no upgrade path from v3 to v4" as stated on the project page? Am I reading that right?

Yes, there's no upgrade path. You can manually convert your v3 custom code to v4 custom code. Or users might try to work together to create an upgrade path. Unfortunately, it's not something I have the resources to work on myself.

Though I love the 4.x concept - the lack of database backing and views integration does really hurt. Are does things within reach?

Views integration:
- base fields will work with a core patch: 📌 Automatically declare computed base fields to Views Needs work
- bundle fields need work in core

Database backing:
I have no idea how to make this work with the current model. Core's computed fields are just that -- they are computed. There is no storage. The model of generating a value and then storing it is more of a dynamic default value. You can maybe experiment with defining a field storage?

Maybe this is not the place - and I also feel dumb to ask this question:

What is the difference between version 4.0 and custom code in a custom module that handles standard fields like this:

/**
 * Calculate special fields ...
 *
 * Implements hook_ENTITY_TYPE_presave()
 */
function MY_MODULE_node_presave($entity) {
  
  switch ($entity->bundle()) {
    // Here you modify only your day content type
    case 'article':	  
...

I could make these fields readonly in the form edit (e.g. using https://www.drupal.org/project/readonly_field_widget → ).

To me the advantage of the older version of computed field was the easy way of making calculations from the UI - without all the file uploads, debugging and cache clears now plugin creations etc ...

Since php in the gui is gone and I have to write code in the backend anyway, what functionality of computed field am I missing?
Please don't get me wrong. I am asking because there must be things I am missing.

ANd thanks for all your work on Drupal! It's great and much appreciated!

> Since php in the gui is gone and I have to write code in the backend anyway, what functionality of computed field am I missing?

Because you don't need to define the field. You only need to write the code that produces the value. And that code is then reusable for any number of fields.

Thanks. I see.

@joachim: What's remaining before we can tag a beta? What's remaining before we can tag a stable release?

Please add these lists to the IS. Thanks! :)

For now, I'm going to make v3 stable to at least prevent folks from getting v2.

> @joachim: What's remaining before we can tag a beta? What's remaining before we can tag a stable release?

Before going to beta, probably figuring out 🐛 Computed field should specify the cardinality of the field Fixed as it might break API.

After that, mostly just waiting to see if there are any more bug reports :)