-
Notifications
You must be signed in to change notification settings - Fork 88
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cut release 1.4.0 #480
Comments
This is the PR for the 1.3.0 release: #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:
p4-language-compatibility
|
Thanks for the guidance, that is very helpful. |
@smolkaj I propose (and volunteer) to create a |
Just for my understanding -- why create an extra branch instead of working directly on |
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. |
What would we do with PRs like #473? IIUC, those PRs would still go into main directly? And the
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. Perhaps a compromise could be to try to submit to |
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. |
Ok, agreed. Staging all the version changes on a shared release branch SGTM. |
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. |
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
EDIT: The cutoff date for changes going into 1.4.0 is September 13, the date of our next P4 API working group meeting.
The text was updated successfully, but these errors were encountered: