Question

Just after a release version we usually switch to Main codeline and work on this until the product is stable enough. At this point we branch the next major version codeline and add finishing touches.

What’s wrong to start working immediately in the next major version branch? We could prepare final the build/test process from the beginning instead of in those busy days at the end of the development.

Thanks.

Answer 1

By ‘release version’ I assume you mean that you have a ‘release branch’, and I assume your question is then why not have just ‘release branches’ instead of many ‘release branch’ and a ‘main branch’.

The ‘best practices’ depends a lot on your methodology, your requirements, your team size
and structure (and maybe on your source control software)
For example, even on a very simple model you need a place where normal development work
continues in parallel with stabilization work.

So, if you had only ‘release branches’ once stabilization work started no new code could be added onto the branch,for it would ruin the stabilization process. So any engineer not directly linked to the stabilization would be unable to check-in.

I usually consider the ‘Main’ branch to be my ideal development line,
a place where code that has passed some minimum correctness criteria from development branches is merged in. This is also where code from bugfixes etc made on the ‘release branches’ is also merged in

I have one or more development branches (it really depends on your team structure) that have fewer correctness criteria where developers can put on code as they like. Once code
in development branches reaches a certain level of maturity is merged into MAIN.

Once code in MAIN has reached again my ideal maturity I create the release branches where stabilization works carries on. From time to time, code from release branches containing
bug fixes is merged back into the MAIN branch.

You may want to check out MS TFS branchign guidance.

Also this white paper from perforce