T , 2011-12-21 14:04 -0500, Geoffrey Hutchison rakstīja: > > IMHO, OBv3 goals have been set some time ago and many of them are completed > > now, so its completion > > should be pursued first since its easier and faster to work with the > > existing code, especially when most of the functionality is already > > there. That should be v3. MolCore could come later after that in v4. > > I'm not going to comment about version numbering. In many software > products (Microsoft?) we're probably already on Open Babel v4 or v5. I > note that Open Eye ships a "babel" program that they call babel v3. We > periodically add features to "point" releases. I don't really care > about what numbering system is used, and I expect most users don't > either. > > That wasn't the point of my message. Those who care about such things > have probably noticed that development still continues on a version > which may be released as v2.4 -- it currently calls itself 2.3.90 or > something. Work will continue. Open Babel will continue to exist, and > new features will be added. >
My point also was not about version numbering, but rather the project v3 which has been documented in OB wiki with its goals. I would like to see them reached. That said, version numbering is not completely irrelevant either, because as far as I know OB strives to have a stable API and ABI, but at some point it has to be broken for fixes and general improvements. So the question is, when this breakage will be allowed? > Believe me, the point is not lost that it's "easier and faster to work > with existing code." The whole reason Open Babel *exists* is because > Open Eye felt they needed to completely rewrite their code "from > scratch." I've been in projects that try to do that, and it's known to > be a bad idea. > > That's not really what MolCore is doing -- there are more than enough > codebases that nothing is being done from scratch. But please feel free > to come over to molcore.org and molcore-de...@lists.sf.net if you'd > like to find out more. > Glad to hear that I got wrong impression in this case. > > There are plenty of things to improve in the existing OB code base to > > make it more robust and easier to work with as a library. I personally > > see that as a more urgent priority > > Great. Suggestions and code contributions (including many which you > have already given) are always welcome. > In our university we have a course on opensource and I'm considering to use that as an excuse to do some OB programming next semester :) I don't have a big programming experience so I would be of little help to design a library, but I was looking at v3 goals and most of them looked doable and some were the pain points when I was using OB as library. > I just felt that giving an e-mail about the past 10 years should give > some forward-looking comments about the next X years. :-) Sure, it is nice or maybe even required to have a clear vision for future development, the post was very much appreciated. To articulate that in a well-defined road map would also be useful. Reinis ------------------------------------------------------------------------------ Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev _______________________________________________ OpenBabel-Devel mailing list OpenBabel-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openbabel-devel
