That sounds like it would be a support nightmare. Unless I misunderstand how you’re going to do this it sounds like there will be 2 different releases of 2.10, and every version thereafter. If I’m running 2.10 from the ‘main’ release and you’re running 2.10 from ‘lenovo’ release we may see different functionality based on the fixes included in each 2.10. If you’re going to differentiate the name in the version string that might work, but why not just call it 2.10.1?
Mike > On Nov 18, 2015, at 3:49 PM, Jarrod Johnson <[email protected]> wrote: > > I wanted to get some feedback on opinions of how to manage a potential > different set of releases…. > > Our testing group at Lenovo may not line up as well with the 'main' release > cycle, so we were thinking of actually doing releases on a different cycle. > Still use the same github repo, just test on a slightly different cycle… > > For example, maybe we would release a 2.10 point release with backported > fixes from 2.11 prior to release of 2.11. Nothing too dramatic, just a > relatively conservative way to get fixes into the most recent stable branch > on our schedule…. > ------------------------------------------------------------------------------ > _______________________________________________ > xCAT-user mailing list > [email protected] <mailto:[email protected]> > https://lists.sourceforge.net/lists/listinfo/xcat-user > <https://lists.sourceforge.net/lists/listinfo/xcat-user>
smime.p7s
Description: S/MIME cryptographic signature
------------------------------------------------------------------------------
_______________________________________________ xCAT-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/xcat-user
