[openstack-dev] [all] [stable] No longer doing stable point releases

Ihar Hrachyshka ihrachys at redhat.com
Mon Jun 1 08:00:47 UTC 2015

Hash: SHA256

On 06/01/2015 02:20 AM, Steve Gordon wrote:
> ----- Original Message -----
>> From: "Maish Saidel-Keesing" <maishsk at maishsk.com> To:
>> openstack-dev at lists.openstack.org
>> On 05/29/15 18:25, Matthew Thode wrote:
>>> 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-request at lists.openstack.org?subject:unsubscribe
>>> for release notes just do git log between commit hashes?
>> Do you really think that is what an Operator will do? I do not
>> think is a realistic expectation or something that will work. -- 
>> Best Regards, Maish Saidel-Keesing
> While I agree most operators probably don't want to necessarily dig
> this out of git themselves and it would need to be collated/exposed
> in a nicer way it seems like it would actually be more accurate
> than the current "release notes" for all the non-security bug fixes
> in stable which basically amount to a list of launchpad bug queries
> per project. You then have to sift through each bug to work out if
> the description reflects what was actually done etc:
> https://wiki.openstack.org/wiki/ReleaseNotes/2014.2.3

I think the section that is really useful is "Known Issues and
Limitations". Sometimes it suggests operators to apply some
configuration changes to their nodes:


Version: GnuPG v2


More information about the OpenStack-dev mailing list