t; >>>>
>> >>>> +1 for that too. We should be on the same page here, but this is
>> >> non-binding. The bylaws state that any PMC member can bring up a
>> release
>> >> for a vote.
>> >>>> - Bobby
>> >>
;
> >>>> +1 for that too. We should be on the same page here, but this is
> >> non-binding. The bylaws state that any PMC member can bring up a
> release
> >> for a vote.
> >>>> - Bobby
> >>>>
> >>>> On Monday, May 9, 20
; wrote:
>>>>
>>>>
>>>> +1. Same here.
>>>>
>>>>> On 5/9/16, 5:47 AM, "John Fang" <xiaojian@alibaba-inc.com> wrote:
>>>>>
>>>>> I'm also think we shouldn't maintain 0.10.x branch
>>>>
xiaojian@alibaba-inc.com> wrote:
> >>
> >>> I'm also think we shouldn't maintain 0.10.x branch
> >>>
> >>> -邮件原件-
> >>> 发件人: Cody Innowhere [mailto:e.neve...@gmail.com]
> >>> 发送时间: 2016年5月9日 19:42
> >>> 收件人: dev@
+1. Same here.
>>
>> On 5/9/16, 5:47 AM, "John Fang" <xiaojian@alibaba-inc.com> wrote:
>>
>>> I'm also think we shouldn't maintain 0.10.x branch
>>>
>>> -邮件原件-
>>> 发件人: Cody Innowhere [mailto:e.neve...@gmail.com]
&g
gt;
> +1. Same here.
>
> On 5/9/16, 5:47 AM, "John Fang" <xiaojian@alibaba-inc.com> wrote:
>
>> I'm also think we shouldn't maintain 0.10.x branch
>>
>> -邮件原件-
>> 发件人: Cody Innowhere [mailto:e.neve...@gmail.com]
>> 发送时间: 2016年
"John Fang" <xiaojian@alibaba-inc.com> wrote:
>I'm also think we shouldn't maintain 0.10.x branch
>
>-邮件原件-
>发件人: Cody Innowhere [mailto:e.neve...@gmail.com]
>发送时间: 2016年5月9日 19:42
>收件人: dev@storm.apache.org
>主题: Re: [DISCUSSION] Version lines of 1.
+1. Same here.
On 5/9/16, 5:47 AM, "John Fang" <xiaojian@alibaba-inc.com> wrote:
>I'm also think we shouldn't maintain 0.10.x branch
>
>-邮件原件-
>发件人: Cody Innowhere [mailto:e.neve...@gmail.com]
>发送时间: 2016年5月9日 19:42
>收件人: dev@storm.apache.org
>主题
I'm also think we shouldn't maintain 0.10.x branch
-邮件原件-
发件人: Cody Innowhere [mailto:e.neve...@gmail.com]
发送时间: 2016年5月9日 19:42
收件人: dev@storm.apache.org
主题: Re: [DISCUSSION] Version lines of 1.x
I'm also +1 for maintaining 1.x branch & master and not maintaining 0.10.x
br
I'm also +1 for maintaining 1.x branch & master and not maintaining 0.10.x
branch.
On Mon, May 9, 2016 at 1:04 PM, Abhishek Agarwal
wrote:
> +1. There is lot development effort pending against 1.x branch which will
> get unblocked with 1.1.0 branch. I am assuming, we will
+1. There is lot development effort pending against 1.x branch which will
get unblocked with 1.1.0 branch. I am assuming, we will not introduce any
backward incompatible changes in the new branch. But what will be the
release timeline of 1.1.0? Many of the PRs affect small portion of code.
Back
What a coincidence! :)
My feeling is that this issue would be another representation of 'drop
further releases of 0.x'.
If we want to have minor and bugfix version separated, we would have at
least 3 branches, master (for 2.0), 1.1.x, 1.0.x. I'm seeing that not all
bugfixes are applied to 0.10.x
Perfect timing as I was thinking about similar things.
The new metrics APIs being proposed against the 1.x branch would be an API
addition, and IMO should bump the minor version when added. I'd be +1 for that.
I guess it comes down to how many version branches do we want to support? We
may
Hi devs,
I have a feeling that we recently try to respect semantic versioning, at
least separating feature updates and bugfixes.
Recently we released 1.0.0 and 1.0.1 continuously, which was OK since it
addressed performance regressions and critical bugs. I'm curious that we
want to maintain
14 matches
Mail list logo