The migration path doesn't work IMHO.
Instead, I propose to keep the name of the column and of the property as is.
Then, on table creation, the column should be indexed, and we should use it to store absolute expiries. We should tell in UPGRADE files which query ppl need to run to add the index to their existing DB.
To have smooth compat with current sessions, to decide when a value in the column is a lifetime or an expiry, we would compare values to 315576000 (10 years): when the number is higher, it's an absolute date, when it's ower, it's a relative date.
GC would be done in two DELETE queries, for >315576000 and <=315576000.
In v6, we would simply drop the <=315576000 one, because in two years we'll be able to consider that all relevant sessions have been migrated to absolute dates.

Thank you @azjezz.

Hello @nicolas-grekas, I think this is a BC break. On mysql, the lifetime column has been for the last few years a MEDIUMINT column.

The new version with time() + $maxlifetime instead of $maxlifetime is higher than the MEDIUMINT mysql limit.

When upgrading from symfony 4.3 to 4.4 with an existing database, we have the error SQLSTATE[22003]: Numeric value out of range: 1264 Out of range value for column 'sess_lifetime' at row 1

I saw the creation of the session table has been fixed 5 days ago in #34410 but that does not fix existing databases.

Is it normal we need to create manually a sql migration for a breaking database schema change, which is not really mentioned in UPGRADE-4.4.md ?

That's an interesting feedback @tseho but please create an issue: nobody is tracking comments on closed PRs.

Thanks for your response and sorry about that, I just created a new issue : #34491