brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Downer <rich...@apache.org>
Subject Re: Call for release: Brooklyn 0.10.0
Date Thu, 17 Nov 2016 13:40:59 GMT
The release-manager-to-be could also start running the release script[1] a
few times in dry run mode to catch any early issues.

[1]
https://github.com/apache/brooklyn-dist/blob/master/release/make-release-artifacts.sh


On 17 November 2016 at 13:09, Aled Sage <aled.sage@gmail.com> wrote:

> +1, sounds great - thanks Andrea!
>
> There are some really import jclouds fixes in 1.9.3-SNAPSHOT (or 2.0.0)
> that we want, such as an OutOfMemoryError deploying to Softlayer [1].
>
> It's worth hanging fire on Brooklyn 0.10.0 until we have a jclouds 1.9.3
> release.
>
> In the meantime, we should still get our own house in order by doing the
> first of the steps below (i.e. dealing with open PRs; ensuring no-one has
> any imminent important contributions to make for 0.10.0, etc).
>
> Aled
>
> [1] https://issues.apache.org/jira/browse/BROOKLYN-364
>
>
>
> On 17/11/2016 11:37, Alex Heneveld wrote:
>
>> That would be a great solution Andrea!
>>
>> Best
>> Alex
>>
>> On 17 Nov 2016 08:18, "Andrea Turli" <andrea.turli@cloudsoftcorp.com>
>> wrote:
>>
>> I'm happy to volunteer for releasing an official jclouds 1.9.3 which may
>>> be
>>> the half-house solution here.
>>>
>>> wdyt?
>>>
>>> Andrea
>>>
>>> On 17 November 2016 at 08:25, Svetoslav Neykov <
>>> svetoslav.neykov@cloudsoftcorp.com> wrote:
>>>
>>> This is going to be the first release that actually works in Karaf. The
>>>> docs are still assuming classic though so I suggest we keep recommending
>>>> the classic distribution for 0.10.0.
>>>> For next release let's plan on updating the docs and switching the
>>>> recommended distribution to the Karaf based one.
>>>>
>>>> Svet.
>>>>
>>>>
>>>> On 16.11.2016 г., at 13:22, Aled Sage <aled.sage@gmail.com> wrote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>> It's far past time that we did a Brooklyn 0.10.0 release! I suggest we
>>>>>
>>>> aim for that soon.
>>>>
>>>>> To that end, I suggest the following steps:
>>>>>
>>>>> * Deal with open PRs:
>>>>>      o People shout out about any PRs you think are very important to
>>>>>        be merged, before that release.
>>>>>      o Review open PRs
>>>>>        (for any that won't get merged into 0.10.0, clearly mark them
as
>>>>>        such and say why).
>>>>> * Any pending/remaining work:
>>>>>      o Give people until Friday evening (uk time) to submit any other
>>>>>        very important PRs that are being working on.
>>>>>      o People shout out about any known issues that they see as
>>>>>        blockers for a release.
>>>>> * Do some initial testing, using master (before Friday).
>>>>> * Aim to produce a first release candidate on Friday evening (uk time).
>>>>> * Do the usual QA/fix cycle until the release is ready.
>>>>> * Write release notes, etc.
>>>>>
>>>>> Of the first steps, reviewing the PRs is a big piece of work! If you
>>>>>
>>>> have time to help, then please lend a hand by reviewing and/or testing
>>>>
>>> the
>>>
>>>> PRs, and commenting on them.
>>>>
>>>>> I don't think we should try to squeeze lots of additional PRs into
>>>>>
>>>> 0.10.0 - there is already a huge amount in there compared to 0.9.0!
>>>>
>>>>> Richard, are our release process docs up-to-date at [1]?
>>>>>
>>>>> Aled
>>>>>
>>>>> [1] http://brooklyn.apache.org/developers/committers/release-
>>>>>
>>>> process/index.html
>>>>
>>>>>
>>>>>
>>>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message