We recently migrate to 4.33 and liquibase computed differently checksum for some of our scripts.
It seems valueDate field is handled differently for checksum computation:
-
liquibase 4.31:
[2025-08-08 14:26:39] FINE [liquibase.util] Computed checksum for 9:74ce2de892e06c1a7ce0e2dea4b6cd7e:9:e1e276f94d77c8bb0a754d106892f4b3:9:661d58ce65ee53be15082922d403fa14:9:e41a7d64ecc8027c12ee572575eb8d43:9:2d93ece03191d495647067b5301eebec:9:bdb5d7c45883440d357a7a91b40b8fe6: as d22a3c94dfe6cbab6333bfacdf9dddbc [2025-08-08 14:26:39] FINE [liquibase.util] Computed checksum for insert:[ 2025-08-08T14:26:39.897526125Z columns=[ 2025-08-08T14:26:39.897527647Z [ 2025-08-08T14:26:39.897528713Z name="id" 2025-08-08T14:26:39.897530086Z value="1" 2025-08-08T14:26:39.897531197Z ], 2025-08-08T14:26:39.897532247Z [ 2025-08-08T14:26:39.897533321Z name="optimistic_lock_version" 2025-08-08T14:26:39.897534483Z value="0" 2025-08-08T14:26:39.897535533Z ], 2025-08-08T14:26:39.897536593Z [ 2025-08-08T14:26:39.897537629Z name="code" 2025-08-08T14:26:39.897538737Z value="ENF" 2025-08-08T14:26:39.897539821Z ], 2025-08-08T14:26:39.897540852Z [ 2025-08-08T14:26:39.897541899Z name="created_on" 2025-08-08T14:26:39.897543016Z valueComputed="now()" 2025-08-08T14:26:39.897544174Z ], 2025-08-08T14:26:39.897545213Z [ 2025-08-08T14:26:39.897546265Z name="updated_on" 2025-08-08T14:26:39.897547377Z valueComputed="now()" 2025-08-08T14:26:39.897548469Z ] 2025-08-08T14:26:39.897549485Z ] 2025-08-08T14:26:39.897550546Z tableName="sector" 2025-08-08T14:26:39.897551679Z ] as 177844b159a30cf36e0f2d04ffb3c339 -
liquibase 4.33:
[2025-08-08 14:43:03] FINE [liquibase.util] Computed checksum for 9:9a0250825cd0ab959aadff19b492acec:9:2b98e82ad1ead1298c6b20eb34b2eb75:9:1eb636f2a774093eaf737cad4b959b63:9:84a27535f7703d2c3adf9f11f31424f3:9:92f94782d5978706023f736e18273ff9:9:17aabbf37fc1597c04b089c85872e5c9: as d8d38937d89747ec8c744bb74d566202 2025-08-08T14:43:03.413068982Z [2025-08-08 14:43:03] FINE [liquibase.util] Computed checksum for insert:[ 2025-08-08T14:43:03.413119951Z columns=[ 2025-08-08T14:43:03.413127042Z [ 2025-08-08T14:43:03.413296677Z name="id" 2025-08-08T14:43:03.413309469Z value="1" 2025-08-08T14:43:03.413315153Z ], 2025-08-08T14:43:03.413319367Z [ 2025-08-08T14:43:03.413323433Z name="optimistic_lock_version" 2025-08-08T14:43:03.413327745Z value="0" 2025-08-08T14:43:03.413332214Z ], 2025-08-08T14:43:03.413336353Z [ 2025-08-08T14:43:03.413340287Z name="code" 2025-08-08T14:43:03.413344609Z value="ENF" 2025-08-08T14:43:03.413348653Z ], 2025-08-08T14:43:03.413352421Z [ 2025-08-08T14:43:03.413375063Z name="created_on" 2025-08-08T14:43:03.413380197Z rawDateValue="now()" 2025-08-08T14:43:03.413384589Z valueComputed="now()" 2025-08-08T14:43:03.413388721Z ], 2025-08-08T14:43:03.413392567Z [ 2025-08-08T14:43:03.413396495Z name="updated_on" 2025-08-08T14:43:03.413400634Z rawDateValue="now()" 2025-08-08T14:43:03.413404690Z valueComputed="now()" 2025-08-08T14:43:03.413438701Z ] 2025-08-08T14:43:03.413466212Z ] 2025-08-08T14:43:03.413471246Z tableName="s... [truncated in log] as 2058aa9445d2d13491f7fb3f1b54eb02
Is it planned to rollback this behavior or do we have to add some validCheckSum to our changesets ?