+1 - Michelle
> On May 26, 2016, at 6:34 AM, Alexander Shorin <kxe...@gmail.com> wrote: > > I think that's better call feature/improvements freeze, since we still > have to commit the code that includes bugfixes. > > +1 > -- > ,,,^..^,,, > > >> On Thu, May 26, 2016 at 12:56 PM, Robert Newson <rnew...@apache.org> wrote: >> +1 for code freeze. >> >> The only changes we will merge to master branches must contribute toward 2.0 >> actually shipping. >> >> I would also not make 2.x.x branches until 2.0 is GA. the first commit on >> all those branches should be the release itself. Subsequent commits are >> backported fixes from master only. >> >> Lets explicitly say that we'll take no work for future enhancements or fixes >> until 2.0 ships. We must get this out. >> >> Sent from my iPhone >> >>> On 26 May 2016, at 09:10, Andy Wenk <andyw...@apache.org> wrote: >>> >>> Hi, >>> >>> in my opinion, everybody is interested to add new features on a stable >>> version of CouchDB. So with a code freeze, everybody is asked to help get >>> 2.0 shipped because then, new features can be added with more focus and on >>> a stable release. >>> >>> For me, this sounds better than branching even though, that some people >>> will work on their own repos. >>> >>> +1 for code freeze >>> >>> Side note: as I am not actively developing, my opinion should be taken with >>> low prio because there might be reasons from others to prefer branching. >>> >>> Thanks to everyone making CouchDB 2.0 great! >>> >>> Andy >>> >>> -- >>> Andy Wenk >>> RockIt! >>> >>> Hamburg / Germany >>> >>> GPG public key: >>> https://pgp.mit.edu/pks/lookup?op=get&search=0x4F1D0C59BC90917D >>> >>>> On 26 May 2016, at 09:42, Jan Lehnardt <j...@apache.org> wrote: >>>> >>>> Hey all, >>>> >>>> last night on IRC Bob brought up a good point: we have ongoing >>>> development going into our repos while we are trying to get 2.0 out the >>>> door. It might be time to split these two. >>>> >>>> Bob suggested a code freeze until we ship a first 2.0 beta. An >>>> alternative would be to branch out 2.x.x and stabilise that, port any >>>> fixes to master, where regular development can occur there. >>>> >>>> Both alternatives have their pros and cons, but I like the aspect of a >>>> code freeze that forces everyone to help get the release build stable. >>>> >>>> That said, I fear that most folks would then just commit to their >>>> personal or other corporate repos (hello Cloudant) and only sync to ASF >>>> repos when the freeze is over, and not help out with the build. >>>> >>>> E.g. I don’t want to force anyone into anything they don’t want to do >>>> with an arbitrary policy, but I’d be in support of a code freeze if >>>> people here would signal that it’d help them focus on a stable build >>>> as opposed to new feature development. >>>> >>>> What do you think? >>>> >>>> Best >>>> Jan >>>> -- >>
