[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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'?
- Julian
Received on 2013-03-13 16:40:25 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.