switched version number in version.gms to 3.0 for release 3.0

[volker-krey]

No description provided.

[khaeru]

Thanks for opening this, @volker-krey.

@zikolach and I spent some time trying to understand this before the release. As a result we deliberately did not change this number. Instead, we updated the comments in the file that you edited here (see the diff), and also added comments in the ixmp Java code; see here, to precisely describe what this is and when it should change.

For posterity, I'll transcribe some more of that discussion here, but will close this PR without merging.

This "version number" is only loosely related to the Python package versions/code of ixmp and message_ix. What it precisely represents (as written in those comments) is the "layout", "format", or "scheme" of the GDX file that is generated by the ixmp_source Java code for use by the message_ix GAMS code. For example, an element all is automatically added to some sets, in a way that's invisible to the Python code.

Some facts about these:

• That GDX file "scheme" changes infrequently. For example, it did not change at all between the 2.0 and 3.0 releases of the Python code.
• Our goal of modular and fully open source code (see Disentangle message_ix and ixmp_source #254) means that nothing special or hidden should happen in the Java ixmp_source code. Once that goal is achieved, the GDX file may not need any version identifier at all.
• In the meantime, incrementing this Java/GDX schema number would introduce friction for users, to no purpose. For example, imagine you generate a GDX file with ixmp master from a few commits before the 3.0 release. Then you try to use that GDX file with the message_ix 3.0 release. During this time, nothing changes in the ixmp_source Java or message_ix GAMS code; the GDX file remains 100% compatible. If this number in version.gms was incremented, then the GAMS code would refuse to read that GDX file. You would be forced, unnecessarily, to regenerate the GDX file or to modify it manually.
• Aside from not serving a purpose, the rule of bumping this number on every release also creates extra work for two people, i.e. the maintainers of ixmp_source, ixmp, and message_ix; it requires three PRs, one for each repo.

The simple rule to be followed is now written in the comment in ixmp_source:

* Increment *only* in the event that the generated GDX contents change in a
* way that requires corresponding changes to the MESSAGE GAMS source.