Cut release 1.4.0

[smolkaj]

We discussed in the P4 API WG meeting that it would be a good time to cut a new release. Opening this as an umbrella bug to track that.

• label open PRs and issues with https://github.com/p4lang/p4runtime/labels/1.4.0 if they should block the release.
  • ideally include all PRs/issue with p4-language-compatibility An issue related to compatibility between P4_16 language spec and P4Runtime API spec label
• close all PRs/issue with label https://github.com/p4lang/p4runtime/labels/1.4.0
• make sure the changelog entry in the spec is up to date.
• Update the Bazel example to use the new release
• Update the version string in the spec .mdk source document. After the release, the version string should be set to 1.5.0-dev on the main branch.
• Update references to the "latest" P4Runtime version in documentation.
• All references in the P4Runtime spec should then be updated to point to the latest released version of the P4 spec.
• After publishing the release on Github, make sure that the PyPi package was uploaded successfully. This happens automatically from Github CI. There will be a CI error if it fails.
  ...

@antoninbas do you have any notes/suggestion on the process you have used in the past?

cc @chrispsommers @jonathan-dilorenzo @jafingerhut

[antoninbas]

This is the PR for the 1.3.0 release: #327

A few things to look out for:

• Update the version string in the spec .mdk source document. After the release, the version string should be set to 1.5.0-dev on the main branch.
• Make sure the changelog entry in the spec is up to date.
• Update the Bazel example to use the new release?
• Update references to the "latest" P4Runtime version in documentation.

After publishing the release on Github, make sure that the PyPi package was uploaded successfully. This happens automatically from Github CI. There will be a CI error if it fails.

I would also recommend making sure that there is full "compatibility" with the latest P4 version. This is a bit tedious, even though in general no change is required. This is also why the 1.4.0 release has been postponed so much (but we have had a few release candidate tags so that people could point to something more recent than 1.3.0). There are still quite a few open issues with the language compatibility label: p4-language-compatibility An issue related to compatibility between P4_16 language spec and P4Runtime API spec . All references in the P4Runtime spec should then be updated to point to the latest released version of the P4 spec.

[smolkaj]

Thanks for the guidance, that is very helpful.

[chrispsommers]

@smolkaj I propose (and volunteer) to create a version-1.4.0-rc branch to which we (anyone in the WG) can collaboratively and incrementally contribute PRs; then we can make PR from this working branch to main. This will allow us to divide and conquer. If this sounds good, I'll get the process started.

[smolkaj]

Just for my understanding -- why create an extra branch instead of working directly on main?

[chrispsommers]

Maybe I'm overthinking the amount of work to make a "release." Ideally there would be a single PR repreasenting the changes to main. In the past this came from one author (e.g. Antonin. If we have one author this time then we could review the one PR. On the other hand, assuming there were a few tasks we could parcel out, we could apply these to an interim branchm then prepare a final consolidated PR with all the changes, then merge that into main.

[smolkaj]

What would we do with PRs like #473? IIUC, those PRs would still go into main directly? And the version-1.4.0-rc branch would be used only for staging the various changes needed for actually cutting the release?

Ideally there would be a single PR repreasenting the changes to main.

I'm open to trying this. But admittedly, I'm a bit skeptical. Google wisdom argues exactly the opposite: it is better to break things up into small, incremental PRs that get submitted to a single main branch one at a time.
This is assuming that it is possible to break things up into small incremental PRs without leaving the main branch in a bad/inconsistent state, which is not allowed.

Perhaps a compromise could be to try to submit to main directly and only revert to using a release branch if submitting directly to main would bring us into a bad state?

[chrispsommers]

Any pending PRs should be done before, and independent of, the new release PR. If you look at #327 the changes are pretty minor, and they don't include any content like would be in pending item #473, they are just updates to the spec version etc. If we had a working branch for this ver 1.4.0 release it would have to sync to any changes made meanwhile to main. Changing all these version numbers throughout the spec to signify a new release should be done atomically.

[smolkaj]

Ok, agreed. Staging all the version changes on a shared release branch SGTM.

[chrispsommers]

Done: https://github.com/p4lang/p4runtime/tree/version-1.4.0-rc

[smolkaj]

Shall we set ourselves a hard deadline before the 2024 P4 Workshop, so we have the release ready in time for the workshop and the roadmap retreat? Wdyt @chrispsommers? cc @jonathan-dilorenzo

EDIT: The date for the workshop will likely be October 3rd.