I'm not sure what you are really asking here. It sounds like you want to be able to know when the TrueCrypt stuff has a new version, and then do a rebuild and repackage of your stuff to include that in some cost effective manner. Based on that as my understanding my first question is really, do you HAVE to do that each time? Is there a proven track record that as TrueCrypt makes changes your stuff has to change also to maintain functionality because there have been a consistent number of breaking changes in the past that cause you to not trust new versions? It sounds to me that one simple suggestion on your end is to establish a published schedule that states openly when you intend on keeping up with releases of related libraries that are part of your product. I think allowing the release schedule of other products that you use in your project to drive your development cycle, while possible admirable on your side, is just an unrealistic expectation to set, especially when some of those components are open-source and have a haphazard release schedule. I think it is often better in business to just set the proper customer expectations and meet THEM consistently from your end. Tell your customers that you current release supports versions x, y, and z of any external components at this time, and then perhaps set a regular schedule to evaluate all new versions and produce an update to your timeline barring any issues that are found. As far as doing this automated goes? I am not sure there is anything out there that would just do this unless you put a ton of effort into automated detection of new builds, downloads, regression testing, rebuilding, etc... Personally, THAT sounds like an entire product in it self.
LinkedIn[^] | Blog[^] | Twitter[^]