diff --git a/doc/source/index.rst b/doc/source/index.rst index 77110639a..f8a5aeab6 100644 --- a/doc/source/index.rst +++ b/doc/source/index.rst @@ -45,6 +45,7 @@ Programming HowTos and Tutorials usage review-guidelines contributing + releasing Developer Docs diff --git a/doc/source/releasing.rst b/doc/source/releasing.rst new file mode 100644 index 000000000..01d425881 --- /dev/null +++ b/doc/source/releasing.rst @@ -0,0 +1,30 @@ +========= +Releasing +========= + +Before you intend to release a new version of neutron-lib consider posting +a `sentinel patch `_ +that will allow to validate that the neutron-lib hash chosen for tagging is +not breaking gate or check jobs affecting a project you care about, first +and foremost Neutron. + +As the patch shows, upper-constraints must be bypassed and that may itself +lead to failures due to upstream package changes. The patch also shows (expected) +Grenade failures in that Grenade pulls its own upper-constraints +file during the upgrade phase. In general a newer version of neutron-lib is +validated through the Tempest -full job (and Grenade runs a subset of it), so +Grenade failures can be safely ignored. + +In any other case consider (for failures caused by unpinned global requirements) +hard-coding a dummy upper-constraints file that itself uses the specific +neutron-lib hash you want to test. Furthermore, consider using a commit header +that starts with DNM (Do Not Merge) to indicate that the change is just a test, +or -2, if you have the right access permissions. + +It is also worth noting that every Stadium project will have a periodic job +running unit tests against the master version of neutron-lib +(`periodic-neutron-py34-with-neutron-lib-master `_ +being an example). Checking Grafana's `periodic `_ +dashboard can give you a glimpse into the sanity of the integration between +neutron-lib and the Stadium projects, and can be considered the quick check +before going ahead with a full blown sentinel patch.