On Feb 14, 2010, at 5:27 AM, Tom Browder wrote: >> Version numbers were specifically hidden from headers to prevent >> developers >> from making compile-time affordances in code for multiple versions >> of API. > > How does that hinder anyone who doesn't want to be hindered?
In a way, it hinders the API developers. In my experience, it causes old interfaces to hang around much longer than is desired and increases support maintenance. Those are two subtle points, and not a "major" issue for either, but they're a burden that I would prefer to avoid entirely if we can. Especially when the need is driven by a non-technical requirement, a non-technical solution is often better. Basically, it's preferring to let the API evolve in a controlled fashion letting external developers not have to maintain multiple interfaces either -- the code works with a given minor revision or you're following a branch (like trunk). >> Exactly what it sounds like you're trying to do to work around the >> signature change.. :) Those "#if version == whatever" compile- >> time checks >> are certainly convenient and simple but they slow down API evolution >> detrimentally and cause added migration burdens for all involved >> down the > > Do you mean BRL-CAD developers? If so, how would it bother them if > BRL-CAD itself didn't use the information? Isn't providing a version > macro something that could be automated since you give each release a > version? I meant "external developers" and external codes that make calls into the BRL-CAD APIs. The burden on their end is increased code entropy to maintain (multiple versions #ifdef'd), which isn't necessarily our direct concern, but a burden we'd be allowing others to take upon themselves. That by itself is a minor point but then there is also a burden for BRL-CAD developers of having to sort through development issues with old API generally longer than usual and in potentially inconsistent manners. Old API code is allowed to linger and worse yet, can unknowingly get intermingled with new API code causing difficult bugs. > The problem is that the other part of the team is doing development > with Windows and they have had problems in the past with BRL-CAD on > Windows and are not as willing to update or install from source as us > *nix people are. That sounds like an area we should be investing effort if it's problems with a current version. Have they repeatedly had problems on Windows *after* doing an update (beyond minor edits to support new API, such as the rt_db_free_internal())? Or just general problems in the past getting things to work? Or are they just resistant to change? If they're like other developers I know where BRL-CAD is a tertiary concern, once things work they don't really want to change anything unless they absolutely have to. The disconnect is that you do, wanting to follow the latest development. Ideally, you'd both follow the latest development. Again, this isn't a show-stopper if we had to make the version available as compile-time definitions, but I'd prefer it be for some technical benefit. In clarifying the reasons through these discussions, I do realize many of the points are presumptuous (and don't mean to be) -- it's more trying to encourage even our external developers to become/be more adaptive so we can evolve and improve faster, avoiding stagnation and complacency because things seem to "work". Cheers! Sean ------------------------------------------------------------------------------ SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev _______________________________________________ BRL-CAD Developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/brlcad-devel
