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 >>> -- >> >
