e2nIEE / pandapower

Convenient Power System Modelling and Analysis based on PYPOWER and pandas
https://www.pandapower.org
Other
847 stars 478 forks source link

intermediate net version tags #1421

Open jkisse opened 2 years ago

jkisse commented 2 years ago

As Daniel described in the pandapipes issue 320, it would make sense to use intermediate net.version labels to differentiate saved networks between the master and develop version (applies to both pandapower and pandapipes)

The proposed format is an added .dev_0, .dev_1 etc. version.parse("0.5.1.dev_0") < version.parse("0.5.1.dev_1") --> True

rbolgaryn commented 2 years ago

Why not just bump up the version number on the develop branch as soon as it is required for backward compatibility?

rbolgaryn commented 2 years ago

here a PEP:

https://www.python.org/dev/peps/pep-0440/

dlohmeier commented 2 years ago

There the suggested versioning is:

0.5.0 0.5.dev1 0.5.1 0.5.dev2

etc.

rbolgaryn commented 2 years ago

== 1.1 # Equal, so 1.1 matches clause == 1.1.0 # Zero padding expands 1.1 to 1.1.0, so it matches clause == 1.1.dev1 # Not equal (dev-release), so 1.1 does not match clause == 1.1a1 # Not equal (pre-release), so 1.1 does not match clause == 1.1.post1 # Not equal (post-release), so 1.1 does not match clause == 1.1.* # Same prefix, so 1.1 matches clause

rbolgaryn commented 2 years ago

version.parse("1.1.1.dev1") < version.parse("1.1.1") Out[39]: True

version.parse("1.1.2.dev1") < version.parse("1.1.1") Out[41]: False

version.parse("1.1.2.dev2") < version.parse("1.1.2.dev3") Out[44]: True

dlohmeier commented 2 years ago

So, since we use hot fix version numbers (3 digits, not just 2), we should also add intermediate dev versions for the next hot release as indicated by Jolando, not the way I put it before...

rbolgaryn commented 2 years ago

and develop branch must then have a higher 3rd digit than the master branch for dev to count

rbolgaryn commented 2 years ago

Decision: we introduce a second variable, "__format_version__".

The format version is set to the current pandapower version as soon as a change in the pandapower format occurs.

Example:

format version = 2.1.0 pandapower version = 2.8.0

new release 2.9.0 changes the pandapower format (a new column is added to net.trafo)

The pandapower version becomes 2.9.0 the format version now becomes 2.9.0

We need to add a test to also cover this (or make sure the current tests cover this).

This way, convert_format.py is not triggered every time a pandapower net is loaded with a new release of pandapower. Instead, it is triggered only if necessary (the format version of pandapower is higher).

rbolgaryn commented 1 year ago

Until the change is implemented, the workaround should be used:

as soon as the release of the version takes place, the first commit on the develop branch should increase the pandapower version. This way, the develop version of pandapower will always trigger convert_format.