Versioning one-shot data packages

My company currently treats “data packages” as software releases and tracks them as such on all avenues.

These data packages (referred to as datapaks) are a combination of SQL scripts containing complete backend configurations of software, additions of settings and rows, alteration or fixing of a front end feature, etc. This is done to prevent anyone from running unwarranted scripts to change a setting or something similar.

We have been kicking around ways to version these datapaks to run through our automation and cannot seem to come up with a way to version them that makes sense. Each datapak has a name and a version number, but the semantic versioning standard does not really apply here because a datapak is typically only run once. When a new fix or change is needed, we have been incrementing the version and wiping out the prior scripts, which is outside of the standard because the datapak does not contain any code from the prior versions.

Each datapak is standalone. When it has been run and the changes have been made, the SQL is typically erased and the same datapak is used again but with a fresh query pad to fill with the next changes. Then we refer to our tracking system and our historic repository of datapaks if we need to dig something up. We do this because making a new datapak with a new name would mean we would need to make a new pipeline and repository for each script every time we need a new datapak, which seems to be too much for what it is worth.

Does anyone know of any standard that could fit this use case for weird versioning?