On Jun 8, 2010, at 9:04 AM, Geoffrey Hutchison wrote: > Our version number policy is that plugins (e.g., new fingerprints, formats, > etc.) can be added along with "point releases" since they only affect one > minor section of the code. In other words, adding MACCS fingerprints doesn't > make any other part of the code more or less stable.
I know the Python policy best, which is x level releases are backwards incompatible x.y level releases add new features x.y.z level releases are bug and security fixes only The difference seems to be in this: > The point release reflects improved bug-fixing and added plugins. The > "plugin" nature is critical, since we (or others) can add code modules > without affecting anyone. We could add a dozen fingerprints, descriptors, > formats, and they're all accessed the same way. Users and code can test for > the presence of different plugins and fail gracefully. This means that OB's versions depends on the architecture, which seems to be an unexpected coupling. Take for example Eclipse, which is massively built on a plug-in architecture. I don't think their version scheme is dependent only on changes to the core plug-in framework. In any case, I understand the scheme now. > our version numbering also emphasizes stability. We don't break other > people's programs lightly, and in turn, we're used by over 30 open source > projects and uncounted others. To point out, stability doesn't depend on version numbers, it's a process thing. Python is used by a lot more projects than OpenBabel, and with more developers, while having larger steps in their version numbers. > The code is already production-quality, but we obviously like to clean up bug > reports and ensure our API enhancements are enough to support users for > another year. > Since the wiki covers released versions (to prevent confusion), there are no > pages on the 2.3 release. The OB code will not support a bitmap format, as > that would require an additional dependency. I suspect Pybel will integrate > the internal depiction routines for v2.3. How do you get people to try out the new features, in order to see if it's production-quality and get bug reports, without having access to documentation about what's available? Historically speaking, the wiki has had references to development versions. You can see traces of that at http://openbabel.org/wiki/Developer:API Development Snapshots - 2.1.x beta API Documentation (Updated monthly) - This is intended for developers working with the bleeding-edge development code from the SVN repository trunk. > The easiest way to develop a new fingerprint is to copy an existing one as > model. You raise a good point that there is not yet an example fingerprint > code. For testing, the new .so can be in a user-specified location using the > environment variable BABEL_LIBDIR. This is how I do *my* development. Where is the documentation for BABEL_LIBDIR ? I looked at all 28 hits for "BABEL_LIBDIR" from Google, but didn't find any description of this. I found a few mentions in the changelog, including this from 2005-09-11 * src/dlhandler_unix.cpp: Add support for multiple search paths for shared format modules. Uses environmental variable BABEL_LIBDIR which can be a colon separated list of paths (e.g. /usr/lib/openbabel:/usr/local/lib/openbabel ...) Note that the code also allows "\n" and "\r" as separators, though I can't figure out why. It also looks like at some point " " was allowed as a separator, but that was removed a few months ago in the dev version because it broke when people had paths with a space in the name. Cheers! Andrew da...@dalkescientific.com ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ OpenBabel-discuss mailing list OpenBabel-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openbabel-discuss
