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 <[email protected]> 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 > -- >
signature.asc
Description: Message signed with OpenPGP using GPGMail
