intermediate net version tags

[jkisse]

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]

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

[rbolgaryn]

here a PEP:

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

[dlohmeier]

There the suggested versioning is:

0.5.0 0.5.dev1 0.5.1 0.5.dev2

etc.

[rbolgaryn]

== 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]

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]

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]

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

[rbolgaryn]

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]

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.