Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[IMP] data: align data versions to release versions #5973

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

LucasLefevre
Copy link
Collaborator

@LucasLefevre LucasLefevre commented Mar 19, 2025

Description:

This commit fixes two issues at once.

Issue 1

Currently, the migration process will ONLY run if the version of the original
data (in json) is smaller than the last version set in the source code
(CURRENT_VERSION). This means that any additional step set outside of the
library is not run without incrementing CURRENT_VERSION in o-spreadsheet.

Example:

  • we bump the latest version to 25 in o-spreadsheet;
  • we push that value in Odoo
  • users start creating spreadsheets in that version so their spreadsheets are
    set to version 25
  • later on, we need to add a migration step for whatever reason in Odoo, we
    assign it to 25.1

=> the migration code will check against the latest version in the source (25)
vs the one in the spreadsheet data (25 as well) and will simply skip the
migration.
So 25.1 will never run...

Issue 2

The current scheme of the incremented integer is impractical when it comes
to figure out which odoo version it matches(*).

Knowing the release version is usefull for bug fixes to know which version of
the code generated the json data.

With this commit, data format version are now aligned with odoo versions
Current master is 18.3. Next, it'll be 18.4, 19.0, 19.1, etc.

(*) o-spreadsheet releases follow the same version numbers as odoo releases.

Task: 4659206

review checklist

  • feature is organized in plugin, or UI components
  • support of duplicate sheet (deep copy)
  • in model/core: ranges are Range object, and can be adapted (adaptRanges)
  • in model/UI: ranges are strings (to show the user)
  • undo-able commands (uses this.history.update)
  • multiuser-able commands (has inverse commands and transformations where needed)
  • new/updated/removed commands are documented
  • exportable in excel
  • translations (_t("qmsdf %s", abc))
  • unit tested
  • clean commented code
  • track breaking changes
  • doc is rebuild (npm run doc)
  • status is correct in Odoo

@robodoo
Copy link
Collaborator

robodoo commented Mar 19, 2025

Pull request status dashboard

@LucasLefevre LucasLefevre force-pushed the master-upgrade-odoo-lul branch 3 times, most recently from 667257c to 977f2a2 Compare March 19, 2025 15:57
@LucasLefevre LucasLefevre force-pushed the master-upgrade-odoo-lul branch from 977f2a2 to e0ff365 Compare March 19, 2025 16:04
@@ -2,555 +2,188 @@ import { toZone } from "../../src/helpers/index";

export const pivotModelData = function (xc: string) {
return {
version: 19,
version: 25,
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not strictly necessary, but I realized it after it was done so... 🤷‍♂️

migrate: (data: any) => any;
}

export function getCurrentVersion() {
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

technically, it's not the "current" version if there was no changes in one saas. Should it be rather named getLatestVersion ? or is it more confusing and getCurrentVersion is clearer even if it's not strictly speaking 100% correct in all cases?

@LucasLefevre LucasLefevre force-pushed the master-upgrade-odoo-lul branch 7 times, most recently from f8792ae to d4d60dd Compare March 20, 2025 13:29
This commit fixes two issues at once.

Issue 1
-------
Currently, the migration process will ONLY run if the version of the original
data (in json) is smaller than the last version set in the source code
(`CURRENT_VERSION`). This means that any additional step set outside of the
library is not run without incrementing CURRENT_VERSION in o-spreadsheet.

Example:
- we bump the latest version to 25 in o-spreadsheet;
- we push that value in Odoo
- users start creating spreadsheets in that version so their spreadsheets are
  set to version 25
- later on, we need to add a migration step for whatever reason in Odoo, we
  assign it to 25.1

=> the migration code will check against the latest version in the source (25)
vs the one in the spreadsheet data (25 as well) and will simply skip the
migration.
So 25.1 will never run...

Issue 2
-------
The current scheme of the incremented integer is impractical when it comes
to figure out which odoo version it matches(*).

Knowing the release version is usefull for bug fixes to know which version of
the code generated the json data.

With this commit, data format version are now aligned with odoo versions
Current master is 18.3. Next, it'll be 18.4, 19.0, 19.1, etc.

(*) o-spreadsheet releases follow the same version numbers as odoo releases.

Task: 4659206
@LucasLefevre LucasLefevre force-pushed the master-upgrade-odoo-lul branch from d4d60dd to 491296d Compare March 20, 2025 13:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants