Is it feasible to have a persisted historic information of when a specific upgradeStep was executed/imported?

[idgserpro]

First of all, we would like to thank @mauritsvanrees for the 1.8.2 release that really improved the usability of this package and the usage of upgradeSteps since because of that improvements we had the idea of this issue.

For the sake of trying to improve Products.GenericSetup even more, even with just suggestions (we're sorry we can't yet do PR's for plone and zope packages, we're still addressing some internal corporate issues with contributor's agreements), we would like to know if it's possible to have a historic record of when specific upgradeSteps were executed.

Why are we asking this? Because you can have 20 upgradeSteps, you can execute just the last one and it's impossible to know which upgradeSteps before the last one were run or not. You already have an upgradeStep internal id, the next step would be to have a persisted list of timestamps when that id was executed/imported.

Since an image is worth a thousand words, something like this comes to mind:

Of course the layout doesn't need to be like this, you can have a link in the upgradeStep title for example. We don't care which layout is chosen as long as the historic record of every upgradeStep import is shown.

Challenges: since we have systems that already run the upgradeSteps but we don't have it's historic, if a new version of Products.GenericSetup would implement this, "NOT EXECUTED" would be incorrect in that case, something along the lines of "Unknown" would be more appropriate.

[mauritsvanrees]

Currently, the only thing we store about this, is a simple mapping from profile id to last applied version. We have a getter and a setter for it.

So when GenericSetup lists an upgrade step as having been applied already, this only means that the last version for the profile is higher than or the same as the target version of this upgrade step. There is currently no other record that is kept of this.

Such extra info could be nice. But it is not a small extension of existing data. It would involve creating a new mapping analogous to _profile_upgrade_versions, for example _profile_upgrades_applied, with data like this:

{
    'my.package:default':
        {'upgrade_step_id_1': [date1, date2, date3],
         'upgrade_step_id_2': [date3]},
    'other.package:default': {},
}

Then in doStep of the upgrade we could update this data.

One danger is that people might remove old upgrade steps from their code and reuse old names, which would give wrong historic data. But nothing would go really wrong.

So: currently this is not available, but it is probably doable to create this.
But I currently don't have plans to implement this myself.

[idgserpro]

Maurits, it's really nice to hear is at least doable. Let the discussion begin!

[jensens]

+1 for more transparency and information on what have happened. In the case of problems, this could save lots of time.