On Mon, Jul 22, 2013 at 1:30 PM, Stephan Beal <sgb...@googlemail.com> wrote: > >> - Ensuring API/ABI compatibility is harder. And this actually >> slows down development because new features have to be >> implemented > > i don't envision us having to work about this. Fossil is not a > library with the same uses as, say, sqlite3. If we have to concern > ourselves with this level of compatibility then fossil has probably > gotten more popular than i expected. In any case, i do not envision > most people using the library - they will have a single binary (built > on top of the library). The library would be there so that fossil can > finally be integrated into places like IDEs.
I'm sorry but I find this a bit confusing. If you want to offer a library where programs can link into, what difference does it make by assuming it will have a small and concrete set of users? That code will need maintenance too, and a compatibility compromise if often necessary for practical reasons. Regards. -- Isaac Jurado "The noblest pleasure is the joy of understanding" Leonardo da Vinci _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
