[p4] Guidelines for codelines?

steve at vance.com steve at vance.com
Mon Nov 17 14:45:01 PST 2008

The release codeline should only be for fixes to defects found in QA on the
release. Fixes found in other releases that need to be ported to that
release qualify through integration.

Think of your use of development codelines (you're really talking multiple,
not just one, right?) as ways to avoid risk to the ongoing releasability
and productivity of your mainline. Some people only integrate to the
mainline because the only want fully qualified and reviewed changes there
and branches help them implement that process.

Feature that may not be done before next release? Branch it. Project with
significant architectural change? Branch it. Prototype or one-off
development? Branch it. Want to be able to check in without necessarily
following the code quality rules on main (with good justification, of
course)? Branch it.


Original Message:
From: Chris Helck Chris.Helck at us.icap.com
Date: 	Mon, 17 Nov 2008 15:58:26 -0500
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

mail2web - Check your email from the web at

More information about the perforce-user mailing list