[p4] Guidelines for codelines?

Mark Hersey mhersey at foliage.com
Mon Nov 17 14:07:11 PST 2008

In general changes should be made on branches when they are:
1.	Long. (Likely to take more time than available until the next
release codeline being created) or
2.	Risky (When confidence is low that the change is going to be
included into the next release)

Changes that are intended for a release must naturally be made into the
release branch (when it exists), but note, these will generally also need to
be integrated into the main line.

A more detailed answer depends somewhat on your integration pattern.  For
example if your verification effort is very expensive and your risk
tolerance to problems is very low then you may want to create a hierarchy of
integration lines.  This pattern is more common in regulated software
development environments.  In this case the most fundamental "main" line
becomes the place where the developers perform  their first software
integration testing. Another way of looking at this is that everyone's work
is regarded as "risky" and so almost all work is done in a branch.
Integration to the mainline, in this context, becomes a very carefully
managed process so that the main line can make "releases" to the next level
of integration upwards with a known quality level. Each release is in this
way more precisely understood as to its contents and to the potential risks
from interactions.

In either pattern, the main line is where you do the bulk of your general
nightly builds and automated tests (you do have an automated build
environment - right?).  With a good quality main you have a good starting
point for your release branches and the release process and related
verification can focus on truly testing what was intended to be new in this
release - rather than starting work on an unknown commodity with each


-----Original Message-----
From: perforce-user-bounces at perforce.com
[mailto:perforce-user-bounces at perforce.com] On Behalf Of Chris Helck
Sent: Monday, November 17, 2008 3:58 PM
To: perforce-user at perforce.com
Subject: [p4] Guidelines for codelines?

We are following the standard development, main, release model and I'm
trying to create guidelines for our developers to help them figure out which
codeline they should work on. My question is when can work be done directly
on the main line? It seems to me the logic goes something like

1. If the change is for a specific release and the release codeline exists
then the change goes on the release codeline.
2. If the change is an experiment, a large open ended change, or for an
unscheduled release then it goes on a development codeline.
3. Everything else can go on the main.

This isn't very crisp and it's bound to be confusing. Can someone suggest a
clearer statement?

Also, I understand some people use the main only for integrations.
When/why is this recommended?

C. Helck

This communication and all information (including, but not limited to,
market prices/levels and data) contained therein (the "Information") is  for
informational purposes only, is confidential, may be legally  privileged and
is the intellectual property of ICAP plc and its affiliates
 ("ICAP") or third parties. No confidentiality or privilege is waived or
lost by any mistransmission. The Information is not, and should not  be
construed as, an offer, bid or solicitation in relation to any  financial
instrument or as an official confirmation of any transaction.
 The Information is not warranted, including, but not limited, as to
completeness, timeliness or accuracy and is subject to change  without
notice. ICAP assumes no liability for use or misuse of the  Information. All
representations and warranties are expressly  disclaimed. The Information
does not necessarily reflect the views of  ICAP. Access to the Information
by anyone else other than the  recipient is unauthorized and any disclosure,
copying, distribution or  any action taken or omitted to be taken in
reliance on it is prohibited. If  you receive this message in error, please
immediately delete it and all  copies of it from your system, destroy any
hard copies of it and  notify the sender.

perforce-user mailing list  -  perforce-user at perforce.com

More information about the perforce-user mailing list