On Sat, 7 Mar 2015 10:57:22 -0500 Jim Jagielski <[email protected]> wrote:
> > > On Mar 7, 2015, at 2:30 AM, William A. Rowe Jr. > > <[email protected]> wrote: > > > > On Thu, 5 Mar 2015 11:19:40 -0500 > > Jim Jagielski <[email protected]> wrote: > > > >> After doing some additional research, I think that the > >> current implementation of NOT allowing duplicates (in > >> APR 1.5/1.6) is BROKEN. In trunk this is determined by > >> a flag w/ the insert statement, but the default *should* > >> be to allow dups. > >> > >> As such, I'd like to adjust 1.5/1.6 to the correct and, > >> afaict, canonical behavior. > > > > I don't believe we can do this, it defies all rational API > > compatibility revisioning policies of any project, anywhere. > > > > If we committed a broken-thing into the 1.x branch, let's move > > forward and ship 2.0 already, complete with the triage for things > > we didn't mean to happen? > > > > Not honoring dups IS A BUG. The above seems to imply that any > patch for any broken feature requires a MMN bump. That is crazy. > apr_skiplist is a skiplist implementation. Skiplists allow > for dups. That we don't is a BUG. No, it's a design error. There's not much helping that... once it ships, that's our implementation. Might caution us to provide more careful code review before n.n.0 releases on new features. The suggestion IIRC was a creation flag to toggle the previously undocumented and previously unsupported addition of dups to the skiplist. That can go into 1.next.0 with no issues at all. Other opinions from APR stability champions?
