On Tue, Jul 30, 2013 at 7:08 PM, Robert Schweikert <rjschwei@suse.com> wrote:
A simple example:
Lets say component A depends on component B. Component A is released as version 1 (A-1) and component B is also released as version 1 (B-1). Now component team B decides to have release number 2 (B-2) and thus component team A gets notified. Component team A can now create a branch of component A and start building against B-2. If the changes to get A-1 to build against B-2 are trivial and A-1 can work with both B-1 and B-2, component team A merges the changes back from the branch and tags A-1 as working with B-1 and B-2. If the changes to A are extensive component team A may decide to have a new release, tag it as release 2 (A-2) and tag it to be working with B-1 and B-2 or only with B-2 if that is the case.
What if A-2 isn't ready in time for release, but A-1 doesn't work with B-2? - Do you punish the "bleeding edge" worker bees of component B by including the ancient B-1 together with A-1? - Do you punish the "stable, time-tested" worker bees of component A(-1) by only including B-2 and dropping A(-*) from the release? - Multiply this by a zoo of 5 or say, 26 components A-Z, and this will get real messy and a lot of integration time will be needed before release. - "Yay, we where able to release component Z-2 just-in-time for release, so it works with the most recent versions of components A to D. Sadly, components H-i to M-j don't work with Z-2 anymore." I think what is intended to be used together should be build and tested together. Or am I overlooking something? Am I overestimating the testing and integration effort? -- Kind regards Christopher 'm4z' Holm / 686f6c6d "We must respect the other fellow's religion, but only in the sense and to the extent that we respect his theory that his wife is beautiful and his children smart." --H. L. Mencken -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org