On 7 June 2013 11:06, <[email protected]> wrote: > > We are proposing to design a new API that makes no attempt at compatibility, > but will hopefully be extensible enough to last for a long time, and at the > same time tidy up rough edges in the code. There are two possible ways of > releasing a new API, and this is where we would like some consumer feedback. > > 1. Release an entirely new library (let's call it NPCRE for now). This would > be > completely separate from the existing library. Once the new library was > released, the old library would not be enhanced, and only security-critical > bugs would be fixed. > > 2. Release a library that somehow supports both APIs, probably with some kind > of "wrapper" that converts the old API to the new one. This should be > possible at least for the most common uses of PCRE, but it may not be > possible to implement an absolutely complete mapping. > > The advantage of NPCRE is that the old library remains available unchanged for > existing code, and if bugs have to be fixed, this can be done without > affecting > the new library. The disadvantage is the existence of two libraries, probably > for a very long time.
To be honest I don't see any problem at releasing a library with a brand new API and calling it PCRE 9.0... :-) -- Giuseppe D'Angelo -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
