Re: What's blocking the 1.8 branch?
From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Wed, 13 Mar 2013 15:39:50 +0000 (GMT)
-- Certified & Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download ----- Original Message ----- > From: C. Michael Pilato <cmpilato_at_collab.net> > To: Subversion Development <dev_at_subversion.apache.org> > Cc: > Sent: Wednesday, 13 March 2013, 9:23 > Subject: What's blocking the 1.8 branch? > > Hey, all. The CollabNetters were talking today about the status of our > codebase, and were trying to enumerate the things which are blocking the > 1.8.x branch. > > * Though we've not seen anything explicitly stating as much, we had the > sense (per his toggling of the task's status on roadmap.html to > "completed") > that Philip has taken the rename work to a place where he's comfortable > branching. > > * svn_node_kind_t and svn_kind_t -- Brane has been working to eliminate that > bit of confusion (which, as an API matter, certainly counts as a release > blocker). > > * There's some discussion ongoing about svn_client_move7()'s API flags. > This needs resolution before releasing, too. > > Those are the things we could come up with. Obviously there will be > numerous bug fixes and performance enhancements and such made to the > codebase between now and the release itself. Paul and Julian are debating > something merge-related; Bert commits a minimum of 241 bug fixes per day; > etc. But does anyone know of other release-branch-blocking activities? For issue #4316 'Merge errors out after resolving conflicts', I am about to make a change to the way 'merge' invokes the conflict resolver callback. This would probably be better done before branching, as it affects APIs although it might not change any API signatures; but I suppose it is not a hard blocker. I have a concern about inconsistency of the flags available to some 'update' and 'switch' APIs which, as a potential API change, would be better resolved before branching, but again is not a hard blocker. There are currently ten open issues marked '1.8.0', including some of the ones mentioned above. I suppose we don't necessarily need to fix such issues before branching? Maybe some of them should be demoted to '1.8-consider'? - JulianReceived on 2013-03-13 16:40:25 CET
This is an archived mail posted to the Subversion Dev mailing list.