+1 (non-binding) or maintaining 1.x branch as it is the base for all the package name change and lots of new features. If we have to discontinue a branch, I would also favor discontinuing 0.10.x .
Hugo > On May 9, 2016, at 8:06 AM, Bobby Evans <[email protected]> wrote: > > +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, 2016 8:20 AM, Aaron. Dossett <[email protected]> > wrote: > > > +1. Same here. > > On 5/9/16, 5:47 AM, "John Fang" <[email protected]> wrote: > >> I'm also think we shouldn't maintain 0.10.x branch >> >> -----邮件原件----- >> 发件人: Cody Innowhere [mailto:[email protected]] >> 发送时间: 2016年5月9日 19:42 >> 收件人: [email protected] >> 主题: 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 <[email protected]> >> 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 <[email protected]> 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 <[email protected]>님이 작성: >>>> >>>>> 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 <[email protected]> >>> 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 >>> >> >> > > >
