[p4] Multiple Dependent Products in Perforce

Slava Imeshev imeshev at yahoo.com
Wed Jul 26 22:11:07 PDT 2006


The best practice that we recommend to our customers and
that we follow ourselves is to treat upstream dependencies
as first-class 3rd party products. Such products are received, 
tested for compatibility and then made a part of the code line. 

If bugs or incompatibilities are found they are reported
back to the organization producing such a 3rd party API,
framework and whatnot and the new release is denied becoming
part of the codeline until it is of required quality.

This means that if the dependency obtained the status of
a product on its own not too early there won't be need for
a repository of the "last/current build results" of the
upstream dependencies.

If you find that you have to the latest and greatest build
of the upstream dependency this means that it was cut out of
the main codeline prematurely. The problem with this is that
changes in the upstream dependency will be constantly
breaking builds for the consumers of that dependency while
breakers are not aware of the damage done downstream. This
breakage is unintentional but nevertheless real and hard
to fix.

The only viable solution to this problem is to return the
artificially/prematurely introduced framework or a platform
back into the main product codeline, develop and build it as
a part of the product until it stabilizes and becomes ready
for separation.

If you have the dependence separation done right build
management becomes no-brainer because there is no need
to handle constantly breaking dependencies.

Hope this helps.

Regards,

Slava Imeshev
www.viewtier.com
Build with pleasure!


----- Original Message ----- 
From: "Dan Weatbrook" <dweatbrook at expedia.com>
To: "Stephen Vance" <steve at vance.com>; "Scott Goldstein" <Scott.Goldstein at bluejungle.com>
Cc: <perforce-user at perforce.com>
Sent: Wednesday, July 26, 2006 7:23 PM
Subject: Re: [p4] Multiple Dependent Products in Perforce


> Check out ivy from jayasoft.org.  You will likely see many ways that you
> may use it to address what you are trying to accomplish.
> 
> Thanks
> Dan W
> 
> -----Original Message-----
> From: perforce-user-bounces at perforce.com
> [mailto:perforce-user-bounces at perforce.com] On Behalf Of Stephen Vance
> Sent: Friday, July 21, 2006 10:57 AM
> To: Scott Goldstein
> Cc: perforce-user at perforce.com
> Subject: Re: [p4] Multiple Dependent Products in Perforce
> 
> There is discussion of this in Laura Wingerd's book Practical Perforce. 
> I also dealt with a number of supporting branching issues in my paper 
> from the Perforce User Conference 98 linked off my web site at 
> http://www.vance.com.
> 
> Steve
> 
> Scott Goldstein wrote:
> > We'll soon be moving to a model in which we have multiple products
> with
> > their own lifecycle which have dependencies.  For example, we'll have
> a
> > platform product and several application products which depend on
> build
> > artifacts from the platform, but each will have their own release
> > schedule.
> >
> >  
> >
> > We're thinking that we'll need some sort of repository for build
> > artifacts from the platform and some way of declaring which version of
> > the platform our applications will require and which build artifacts
> > from the platform they'll require.
> >
> >  
> >
> > Can anyone point me to examples or a best practices document for how
> one
> > my set up a source control and build environment for this situation?
> >



More information about the perforce-user mailing list