[DISCUSSION] Version lines of 1.x

[Jungtaek Lim <ka...@gmail.com>]

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 minor version line and bugfix version line for 1.x version
lines. (meaning two version lines for 1.x)

In fact, we discussed to freeze the feature during releasing 2.0.0, but we
don't have timeframe for 2.0.0 and phase 1 is not completed yet, so I don't
think we can freeze developing or improving the features for 1.x lines.

There're many pending pull requests for 1.x (and master, maybe) but not
sure I can merge them into 1.x-branch. In order to address them we should
settle this.

What do you think?

Thanks,
Jungtaek Lim (HeartSaVioR)

答复: [DISCUSSION] Version lines of 1.x

[John Fang <xi...@alibaba-inc.com>]

I'm also think we shouldn't maintain 0.10.x branch

-----邮件原件-----
发件人: Cody Innowhere [mailto:e.neverme@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 branch.

On Mon, May 9, 2016 at 1:04 PM, Abhishek Agarwal <ab...@gmail.com>
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 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 porting these minor improvements as well as bugs into three 
> branches will be counter productive. We might as well work with 1.0.x 
> and keep pushing the changes there.
>
> On Mon, May 9, 2016 at 8:50 AM, Jungtaek Lim <ka...@gmail.com> wrote:
>
> > 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 when we're pointing 
> > 1.x-branch as next release, which means even maintaining 3 branches 
> > are not easy. (It should be addressed if we maintain two 1.x version 
> > lines.) Moreover, package name change makes us a bit bothering to 
> > backport into 0.10.x.
> >
> > So, I'm sorry for 0.x users but I'm in favor of not maintaining 
> > 0.10.x branch.
> > I'm curious what we all think about this, too.
> >
> > 2016년 5월 9일 (월) 오전 11:10, P. Taylor Goetz <pt...@gmail.com>님이 작성:
> >
> > > 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 need to divide and conquer to support that.
> > >
> > > -Taylor
> > >
> > > > On May 8, 2016, at 9:51 PM, Jungtaek Lim <ka...@gmail.com> wrote:
> > > >
> > > > 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 minor version line and bugfix version line for 
> > > > 1.x
> > > version
> > > > lines. (meaning two version lines for 1.x)
> > > >
> > > > In fact, we discussed to freeze the feature during releasing 
> > > > 2.0.0,
> but
> > > we
> > > > don't have timeframe for 2.0.0 and phase 1 is not completed yet, 
> > > > so I
> > > don't
> > > > think we can freeze developing or improving the features for 1.x
> lines.
> > > >
> > > > There're many pending pull requests for 1.x (and master, maybe) 
> > > > but
> not
> > > > sure I can merge them into 1.x-branch. In order to address them 
> > > > we
> > should
> > > > settle this.
> > > >
> > > > What do you think?
> > > >
> > > > Thanks,
> > > > Jungtaek Lim (HeartSaVioR)
> > >
> >
>
>
>
> --
> Regards,
> Abhishek Agarwal
>

Re: [DISCUSSION] Version lines of 1.x

[Cody Innowhere <e....@gmail.com>]

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 <ab...@gmail.com>
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 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 porting these minor improvements as well as bugs into three branches
> will be counter productive. We might as well work with 1.0.x and keep
> pushing the changes there.
>
> On Mon, May 9, 2016 at 8:50 AM, Jungtaek Lim <ka...@gmail.com> wrote:
>
> > 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 when we're pointing 1.x-branch as next
> > release, which means even maintaining 3 branches are not easy. (It should
> > be addressed if we maintain two 1.x version lines.)
> > Moreover, package name change makes us a bit bothering to backport into
> > 0.10.x.
> >
> > So, I'm sorry for 0.x users but I'm in favor of not maintaining 0.10.x
> > branch.
> > I'm curious what we all think about this, too.
> >
> > 2016년 5월 9일 (월) 오전 11:10, P. Taylor Goetz <pt...@gmail.com>님이 작성:
> >
> > > 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 need to divide and conquer to support that.
> > >
> > > -Taylor
> > >
> > > > On May 8, 2016, at 9:51 PM, Jungtaek Lim <ka...@gmail.com> wrote:
> > > >
> > > > 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 minor version line and bugfix version line for 1.x
> > > version
> > > > lines. (meaning two version lines for 1.x)
> > > >
> > > > In fact, we discussed to freeze the feature during releasing 2.0.0,
> but
> > > we
> > > > don't have timeframe for 2.0.0 and phase 1 is not completed yet, so I
> > > don't
> > > > think we can freeze developing or improving the features for 1.x
> lines.
> > > >
> > > > There're many pending pull requests for 1.x (and master, maybe) but
> not
> > > > sure I can merge them into 1.x-branch. In order to address them we
> > should
> > > > settle this.
> > > >
> > > > What do you think?
> > > >
> > > > Thanks,
> > > > Jungtaek Lim (HeartSaVioR)
> > >
> >
>
>
>
> --
> Regards,
> Abhishek Agarwal
>

Re: [DISCUSSION] Version lines of 1.x

[Abhishek Agarwal <ab...@gmail.com>]

+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 porting these minor improvements as well as bugs into three branches
will be counter productive. We might as well work with 1.0.x and keep
pushing the changes there.

On Mon, May 9, 2016 at 8:50 AM, Jungtaek Lim <ka...@gmail.com> wrote:

> 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 when we're pointing 1.x-branch as next
> release, which means even maintaining 3 branches are not easy. (It should
> be addressed if we maintain two 1.x version lines.)
> Moreover, package name change makes us a bit bothering to backport into
> 0.10.x.
>
> So, I'm sorry for 0.x users but I'm in favor of not maintaining 0.10.x
> branch.
> I'm curious what we all think about this, too.
>
> 2016년 5월 9일 (월) 오전 11:10, P. Taylor Goetz <pt...@gmail.com>님이 작성:
>
> > 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 need to divide and conquer to support that.
> >
> > -Taylor
> >
> > > On May 8, 2016, at 9:51 PM, Jungtaek Lim <ka...@gmail.com> wrote:
> > >
> > > 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 minor version line and bugfix version line for 1.x
> > version
> > > lines. (meaning two version lines for 1.x)
> > >
> > > In fact, we discussed to freeze the feature during releasing 2.0.0, but
> > we
> > > don't have timeframe for 2.0.0 and phase 1 is not completed yet, so I
> > don't
> > > think we can freeze developing or improving the features for 1.x lines.
> > >
> > > There're many pending pull requests for 1.x (and master, maybe) but not
> > > sure I can merge them into 1.x-branch. In order to address them we
> should
> > > settle this.
> > >
> > > What do you think?
> > >
> > > Thanks,
> > > Jungtaek Lim (HeartSaVioR)
> >
>



-- 
Regards,
Abhishek Agarwal

Re: [DISCUSSION] Version lines of 1.x

[Jungtaek Lim <ka...@gmail.com>]

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 when we're pointing 1.x-branch as next
release, which means even maintaining 3 branches are not easy. (It should
be addressed if we maintain two 1.x version lines.)
Moreover, package name change makes us a bit bothering to backport into
0.10.x.

So, I'm sorry for 0.x users but I'm in favor of not maintaining 0.10.x
branch.
I'm curious what we all think about this, too.

2016년 5월 9일 (월) 오전 11:10, P. Taylor Goetz <pt...@gmail.com>님이 작성:

> 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 need to divide and conquer to support that.
>
> -Taylor
>
> > On May 8, 2016, at 9:51 PM, Jungtaek Lim <ka...@gmail.com> wrote:
> >
> > 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 minor version line and bugfix version line for 1.x
> version
> > lines. (meaning two version lines for 1.x)
> >
> > In fact, we discussed to freeze the feature during releasing 2.0.0, but
> we
> > don't have timeframe for 2.0.0 and phase 1 is not completed yet, so I
> don't
> > think we can freeze developing or improving the features for 1.x lines.
> >
> > There're many pending pull requests for 1.x (and master, maybe) but not
> > sure I can merge them into 1.x-branch. In order to address them we should
> > settle this.
> >
> > What do you think?
> >
> > Thanks,
> > Jungtaek Lim (HeartSaVioR)
>

Re: [DISCUSSION] Version lines of 1.x

["P. Taylor Goetz" <pt...@gmail.com>]

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 need to divide and conquer to support that.

-Taylor

> On May 8, 2016, at 9:51 PM, Jungtaek Lim <ka...@gmail.com> wrote:
> 
> 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 minor version line and bugfix version line for 1.x version
> lines. (meaning two version lines for 1.x)
> 
> In fact, we discussed to freeze the feature during releasing 2.0.0, but we
> don't have timeframe for 2.0.0 and phase 1 is not completed yet, so I don't
> think we can freeze developing or improving the features for 1.x lines.
> 
> There're many pending pull requests for 1.x (and master, maybe) but not
> sure I can merge them into 1.x-branch. In order to address them we should
> settle this.
> 
> What do you think?
> 
> Thanks,
> Jungtaek Lim (HeartSaVioR)