search

p4lang / p4runtime

Specification documents for the P4Runtime control-plane API
Apache License 2.0
140 stars 86 forks source link

Cut release 1.4.0 #480

Open smolkaj opened 1 month ago

smolkaj commented 1 month ago

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.

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

cc @chrispsommers @jonathan-dilorenzo @jafingerhut

antoninbas commented 1 month ago

This is the PR for the 1.3.0 release: https://github.com/p4lang/p4runtime/pull/327

A few things to look out for:

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: https://github.com/p4lang/p4runtime/labels/p4-language-compatibility. All references in the P4Runtime spec should then be updated to point to the latest released version of the P4 spec.

smolkaj commented 1 month ago

Thanks for the guidance, that is very helpful.

chrispsommers commented 1 month ago

@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 commented 1 month ago

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

chrispsommers commented 1 month ago

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 commented 1 month ago

What would we do with PRs like https://github.com/p4lang/p4runtime/pull/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 commented 1 month ago

Any pending PRs should be done before, and independent of, the new release PR. If you look at https://github.com/p4lang/p4runtime/pull/327 the changes are pretty minor, and they don't include any content like would be in pending item https://github.com/p4lang/p4runtime/pull/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 commented 1 month ago

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

chrispsommers commented 1 month ago

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

smolkaj commented 2 weeks ago

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.