Make releases

[mem]

In order to support packaging p4-hlir in Linux distributions, it would be helpful if you could make releases here on Github. Since you are already assigning a version number to a particular commit, this should be as easy as pushing a button.

[mem]

Also along that line, would it be possible to clarify when the version number changes? Does a version number change signal the start or the end of a development cycle?

[antoninbas]

We haven't been paying a lot of attention to versioning for p4-hlir, so I confess increasing the version number has been pretty random. With P4 evolving, we'd like to be able to improve this. Maybe a part of the version number should reflect the P4 version supported? Any suggestions?

[mem]

I was actually thinking about this...

One option is to use a version like 1.0.x to indicate that the program implements support for P4 1.0, and x is just the release within p4-hlir itself. I'm assuming P4 will remain using an n.m version format.

The other option is to put the version of P4 in the name of the program itself: p4-1.0-hlir, and have a version number for that.

Between the two, I kind of prefer the later, unless you are willing to add a flag to switch between P4 versions (p4-validate --p4 1.0).

The other aspect of this, which is what I was reporting originally, is the need to make releases in this repository. You can either change the version number as the first thing you do after making a release, or the last thing you do before making a release. Either way, some commit needs to be tagged as the release. You can also have something like the first thing after making a release (e.g. 1.24) is changing the version number adding "dev" (1.25-dev) and the last thing you do before making the release is removing the "dev" (1.25-dev → 1.25).

Thanks!

[antoninbas]

Thanks for your suggestions. I think we should start adopting better practices with the release of p4v1.1 (the release candidate is on p4.org, we are still working on the p4-hlir implementation).
Let's start with release tagging. I personally like your last suggestion (1.25-dev -> 1.25) best. We can probably send an email to the p4-dev mailing list to see how people are feeling about it.
The other point is trickier. p4-hlir is a Python package. It is not itself a compiler, but a tool to write target-specific compilers. it comes with the p4-validate binary which performs semantic checking on a P4 program. As a Python package, there can be only one version of the package installed on the system. Installing a latest version (whether with pip or setuptools) overwrites the previous version. Your second option (p4-1.0-hlir) solves this problem by encoding the version in the package name. This means that compiler writers also have to import the correct Python package which I believe is okay. I believe we can go with the following:

• encoding the p4 version in the name: we would have p4-1.0-hlir and p4-1.1-hlir. It would be great if we could find a way to have p4-hlir point to the latest version of the package, but I don't know if this can be done with Python packages.
• each p4-x.y-hlir can have a "patch" number z for bug fix releases, making the full version number x.y.z

It is kind of a mix of your 2 options. What do you think?
The P4 specifications also have a "patch" number. That could be confusing to have a different system for spec patch numbers and p4-hlir patch numbers.
We can run this by the mailing list as well before the p4-hlir v1.1 release. Sorry for the long post, I was just dumping my thoughts here :)