[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
risk).

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:
http://www.cmcrossroads.com/bradapp/acme/branching/branch-structs.html#Mainline

Cheers,
Gabor

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