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