[p4] Codelines and Components
daf at vmware.com
Thu Nov 20 13:30:59 PST 2008
So very true... I'm just fighting a massive inertia where everybody wants to go toward unit-testing the components and enforcing the compatibility requirements, but nobody is willing to actually identify the interfaces themselves because the components were treated as a single ball of mud so long that they're massively incestuous.
However, just because you've set up the directories so that they can be released independently doesn't mean that you must do that. You can still branch each and every one of them as a single unit and treat them that way if you want, you're just not obligated to. If, sometime in the future, you can start splitting off pieces and treating them independently, this format gives you a head-start on that without significantly onerous overhead, I believe.
But, maybe I'm just too frustrated with the past couple of weeks and have lost my objectivity...
From: jeff.a.bowles at gmail.com [mailto:jeff.a.bowles at gmail.com] On Behalf Of Jeff A. Bowles
Sent: Thursday, November 20, 2008 1:22 PM
To: David Ferguson
Cc: Matt Craighead; Chris Helck; perforce-user at perforce.com
Subject: Re: [p4] Codelines and Components
Sure. The only hitch is, you live or die based on the quality of the unit-tests of each component.
If you are in a company with a strong culture of very formal API interfaces between components, strict unit-testing of each method in those components, and some sort of "I'm the wrong version of the component to load with version 2.1 of this other component" support at run-time...
.... then it works well. Really well. Practically wonderfully.
Only you know if you have that sort of culture.
(If you don't, however, then the "separate component" models develop very nicely until they (often) fall apart when deployed to the QA group or, worse, in the customer's hands.)
On Thu, Nov 20, 2008 at 11:52 AM, David Ferguson <daf at vmware.com<mailto:daf at vmware.com>> wrote:
An individual release schedule for each component promotes cleaner interfaces and abstraction. When all components branch together, the seduction of simplistic integrations is pretty successful. Using independent chunks of code helps isolate a component and ensure formally defined interfaces since they never know who is going to consume them when.
More information about the perforce-user