title: Do I have to build my program on the oldest Linux OS minor version I want to support?
body: <p>If I want my software to run on Red Hat Linux 6.0, do I have to build it on 6.0?  Or can I build it on 6.3?  (Similar question for 5.X)  I'm asking a general question about runtime implications of shared libraries and similar "automatic" dependencies that get sucked in during the build process.  And I'm interested only in the divergence between minor releases.  I know that more things change between major releases.  I'm interesting specifically in RH and RH-derived distributions. My program is written in C and C++.  I think the biggest dependency I need to worry about is the GCC runtime libraries for C and C++.  Is there a web page I can use to verify which GCC updates were used in which RH minor releases?</p>
  
  <p>To be clear: I understand the goal and commitment to compatibility between update releases going forward.  Upgrading from 6.1 to 6.2 should not break my existing applications.  In order to build on a newer update and run on an older update, I would need the reverse kind of compatibility.  I need 6.1 to be compatible with things built on 6.2.  In general this kind of compatibility is impossible to achieve on a wide-spread basis, across all config files, libraries etc.  But I only need a narrow slice of reverse compatibility.</p>
  
  <p>I have an app that was designed, written and built successfully on 6.1.  Now I want to build it on 6.2, but I want it to still run correctly on 6.1.  Is there a general software release practice on Linux that you always have to build on the oldest update release that you want to support?  Or do most people use trial-and-error to determine whether their app runs on older update releases?  If you use trial-and-error, how much "error" shows up in the equation?</p>