[p4] Guidelines for codelines?

Gabor Maghera gmaghera at gmail.com
Mon Nov 17 13:59:46 PST 2008

My understanding of the classic mainline model is the following.

1.  High-risk changes go into a development codeline.
2.  All other changes go into main, with one exception, stabilization
changes during the near-release-phase (after all desired features and
fucntionality had been added).
3.  When nearing a release, you would branch a release codeline from
main.  You would only put changes which stabilize the codeline into
it, such as fixes to bugs which QA has found in a previous build.  The
release codeline would not receive any changes which introduce new
features or functionality (and have the potential of introducing

As far as communicating it to the developers, I would establish and
publish a codeline policy, outlining what changes can go inside it
(main does not neccesarily need one).  The developer will likely have
a good idea which project they are submitting the change to, which
then could be translated to a codeline using your policy document.

There are shops  where the classic mainline model does not work
(typically larger companies, maintaining multiple versions of a
product).  In such places developers are not allowed to submit into
main.  The only changes to main are done via integrations from other
codelines.  This would call for a different approach when deciding
where to check changes into, and it blurs the difference between
release and development codelines somewhat.

I would recommend first deciding on the mainline pattern which fits
your environment best.  Your pattern choice is strongly linked to the
policies used when submitting changes.

Here is a page which outlines a few variants of the mainline pattern:


On Mon, Nov 17, 2008 at 12:58 PM, Chris Helck <Chris.Helck at us.icap.com> wrote:
> 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
> this:
> 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?
> Thanks,
> 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
> http://maillist.perforce.com/mailman/listinfo/perforce-user

More information about the perforce-user mailing list