incubator-blur-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Rohr <rohr.ch...@gmail.com>
Subject Re: Release proposal
Date Wed, 04 Sep 2013 23:53:16 GMT
Do you want me to try to get the console finished before code freeze?

On Sep 4, 2013, at 6:29 PM, Aaron McCurry <amccurry@gmail.com> wrote:

> I have been reading through the release notes (I know that we will be
> making changes to them as needed).  Should we branch for the release
> "0.2-dev" and tag "0.2.0" so that we know what was in the release?  Or
> should we branch each time?  So that "0.2.0" is a branch, and we branch
> from "0.2.0" to make "0.2.1"?
> 
> On side a note, I think that unless there is a bug fix needed for "0.2.0"
> that we should just work toward "0.3.0" and have that release within a
> month.  What do you all think?
> 
> Aaron
> 
> 
> On Wed, Sep 4, 2013 at 9:16 AM, Aaron McCurry <amccurry@gmail.com> wrote:
> 
>> Awesome thanks Chris!  And good luck!
>> 
>> Aaron
>> 
>> 
>> On Wed, Sep 4, 2013 at 9:10 AM, Chris Rohr <rohr.chris@gmail.com> wrote:
>> 
>>> I just commented on the Blur Console ticket with the last remaining items
>>> that don't work.  I can try to fix them tonight (assuming my wife doesn't
>>> go into labor).
>>> 
>>> Chris
>>> 
>>> On Sep 4, 2013, at 6:55 AM, Aaron McCurry <amccurry@gmail.com> wrote:
>>> 
>>>> That is good with me. I do have one request. Can I leave the factory
>>> code I put in to allow for the creation of the block cache?  It's pretty
>>> harmless code and has no effect on configuration.  Once I remove the v2
>>> block cache I think we can consider a code freeze.
>>>> 
>>>> Aaron
>>>> 
>>>> Sent from my iPhone
>>>> 
>>>> On Sep 3, 2013, at 11:14 PM, Tim Williams <williamstw@gmail.com> wrote:
>>>> 
>>>>> I meant to add, I reckon this'd mean we'd pull back the block cache-v2
>>>>> stuff for this release...
>>>>> 
>>>>> On Tuesday, September 3, 2013, Tim Williams wrote:
>>>>> 
>>>>>> I've been editing HowToRelease[1] in anticipation of an upcoming
>>>>>> release.  I'd like to propose instead that we just do the release
and
>>>>>> edit that with the commands/procedures that we actually perform.
The
>>>>>> rationale is that some of preferred methods have changed (e.g.
>>>>>> svn-based vs. p.a.o/dist) and it'd be easiest for the RM to just
>>>>>> update it as they go along.
>>>>>> 
>>>>>> Are there any open issues blocking a release?
>>>>>> 
>>>>>> Can we consider a code-freeze on master for a couple days?
>>>>>> 
>>>>>> If no to both, any problems with creating a release candidate tomorrow
>>>>>> and letting it run 72hrs?
>>>>>> 
>>>>>> Or, an alternate proposal?
>>>>>> 
>>>>>> Thanks,
>>>>>> --tim
>>>>>> 
>>>>>> [1] - https://wiki.apache.org/blur/HowToRelease
>>>>>> 
>>> 
>>> 
>> 


Mime
View raw message