Robert Collins wrote: > On 19 August 2015 at 21:19, Thierry Carrez <thie...@openstack.org> wrote: >>> Processing: >>> 1) determine the revisions we need to generate release notes for. By >>> default generate notes for the current minor release. (E.g. if the >>> tree version is 1.2.3.dev4 we would generate release notes for 1.2.0, >>> 1.2.1, 1.2.2, 1.2.3[which dev4 is leading up to]). >> >> How would that work in a post-versioned world ? What would you generate >> if the tree version is 1.2.3.post12 ? > > 1.2.3 is still the version, not that we can use post versions at all > with pbr. (Short story - we can't because we used them wrongly and we > haven't had nearly enough time to flush out remaining instances in the > wild).
Could you expand on that ? Feels like I'm missing a piece of the puzzle. Let's say we just tagged 1.2.3. The next commit is a security fix (for which we don't know the OSSA number yet). The one after that is the release-notes/???.yaml change which specifies the OSSA number in the release notes. At this point we still have no idea what the next version number will look like, since there is no tag yet. What should the filename for ???.yaml be in that case ? If you workaround that by referencing the OSSA in the changes/$ChangeID.yaml file instead, what (if any) work-in-progress .md file does that end up generating ? If we want to serve partial release notes for people consuming the stable branch between tag points, for repositories using post-versioning we have to produce some "next.md" or "in-progress.md" since we can't guess what the next version will actually be. >> [...] >>> If we want to put release notes in sdists, we can have pbr do this, >>> otherwise it could just be built entirely separately. >> >> I think we need to put release notes in sdists, so that people consuming >> stable branches from a random commit can still get work-in-progress >> releasenotes for the upcoming version. > > Those two things are disconnected. Consuming a random commit doesn't > imply sdist - nor does it preclude it. > > We don't *currently* generate release notes in sdists. Whats the > driver for adding it? [perhaps as a use case so we can flush out > hidden assumptions we have] The whole idea behind moving away from coordinated stable branch releases is to let people consume the stable branch at any point in time. The original plan was to stop releasing (tagging) stable branches completely. People replied they still needed "release notes" so that they have upgrade warnings and other bits of information about what they are getting. It's inconvenient to continue using wiki pages to achieve that, so we moved to in-git maintenance of release notes. And rather than force consumers to generate them from the tree, they can conveniently find them in any stable source code tarball we publish (including intermediary ones like $project-stable-kilo.tar.gz). Since then, replying to another concern about common downstream reference points, we moved to "tagging everything", then replying to Clark's pollution remark, to "tag from time to time". That doesn't remove the need to *conveniently* ship the best release notes we can with every commit. Including them in every code tarball (and relying on well-known python sdist commands to generate them for those consuming the git tree directly) sounded like the most accessible way to do it, which the related thread on the Ops ML confirmed. But then I'm (and maybe they are) still open to alternative suggestions... Hope this clarifies, -- Thierry Carrez (ttx) __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
