On 05/29/2015 10:18 AM, Ihar Hrachyshka wrote: > What about release notes? How can we now communicate some changes that > require operator consideration or action? > > Ihar > > On 05/29/2015 03:41 PM, Thierry Carrez wrote: >> Hi everyone, > >> TL;DR: - We propose to stop tagging coordinated point releases >> (like 2015.1.1) - We continue maintaining stable branches as a >> trusted source of stable updates for all projects though > >> Long version: > >> At the "stable branch" session in Vancouver we discussed recent >> evolutions in the stable team processes and how to further adapt >> the work of the team in a "big tent" world. > >> One of the key questions there was whether we should continue >> doing stable point releases. Those were basically tags with the >> same version number ("2015.1.1") that we would periodically push to >> the stable branches for all projects. > >> Those create three problems. > >> (1) Projects do not all follow the same versioning, so some >> projects (like Swift) were not part of the "stable point releases". >> More and more projects are considering issuing intermediary >> releases (like Swift does), like Ironic. That would result in a >> variety of version numbers, and ultimately less and less projects >> being able to have a common "2015.1.1"-like version. > >> (2) Producing those costs a non-trivial amount of effort on a very >> small team of volunteers, especially with projects caring about >> stable branches in various amounts. We were constantly missing the >> pre-announced dates on those ones. Looks like that effort could be >> better spent improving the stable branches themselves and keeping >> them working. > >> (3) The resulting "stable point releases" are mostly useless. >> Stable branches are supposed to be always usable, and the >> "released" version did not undergo significantly more testing. >> Issuing them actually discourages people from taking whatever point >> in stable branches makes the most sense for them, testing and >> deploying that. > >> The suggestion we made during that session (and which was approved >> by the session participants) is therefore to just get rid of the >> "stable point release" concept altogether for non-libraries. That >> said: > >> - we'd still do individual point releases for libraries (for >> critical bugs and security issues), so that you can still depend on >> a specific version there > >> - we'd still very much maintain stable branches (and actually focus >> our efforts on that work) to ensure they are a continuous source of >> safe upgrades for users of a given series > >> Now we realize that the cross-section of our community which was >> present in that session might not fully represent the consumers of >> those artifacts, which is why we expand the discussion on this >> mailing-list (and soon on the operators ML). > >> If you were a consumer of those and will miss them, please explain >> why. In particular, please let us know how consuming that version >> (which was only made available every n months) is significantly >> better than picking your preferred time and get all the current >> stable branch HEADs at that time. > >> Thanks in advance for your feedback, > >> [1] https://etherpad.openstack.org/p/YVR-relmgt-stable-branch > > > __________________________________________________________________________ > 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 >
for release notes just do git log between commit hashes? -- -- Matthew Thode (prometheanfire)
signature.asc
Description: OpenPGP digital signature
__________________________________________________________________________ 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