Project Management question # 1 - CM Branching
-
I'm working on a new project of about 7 developers that may grow to 20 over the next few years. I want to know which branching approach is most favored for this size of a team/project. 1) All development is done off the main trunk, with branches created for each release and for "major" subproject work. Emergency bug fixes are done on the corresponding release branch. 2) Each developer has their own branch which is merged to the main trunk to produce a release. 3) Other
Rocket science is more fun when you actually have rockets - US Navy ad
-
I'm working on a new project of about 7 developers that may grow to 20 over the next few years. I want to know which branching approach is most favored for this size of a team/project. 1) All development is done off the main trunk, with branches created for each release and for "major" subproject work. Emergency bug fixes are done on the corresponding release branch. 2) Each developer has their own branch which is merged to the main trunk to produce a release. 3) Other
Rocket science is more fun when you actually have rockets - US Navy ad
Seems to me 1 makes the most sense. It's certainly what I use for my own projects.
¡El diablo está en mis pantalones! ¡Mire, mire! Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF! VCF Blog
-
I'm working on a new project of about 7 developers that may grow to 20 over the next few years. I want to know which branching approach is most favored for this size of a team/project. 1) All development is done off the main trunk, with branches created for each release and for "major" subproject work. Emergency bug fixes are done on the corresponding release branch. 2) Each developer has their own branch which is merged to the main trunk to produce a release. 3) Other
Rocket science is more fun when you actually have rockets - US Navy ad
1 is the easiest approach IMO I aways do this.
Ant. I'm hard, yet soft.
I'm coloured, yet clear.
I'm fruity and sweet.
I'm jelly, what am I? Muse on it further, I shall return! - David Walliams (Little Britain) -
I'm working on a new project of about 7 developers that may grow to 20 over the next few years. I want to know which branching approach is most favored for this size of a team/project. 1) All development is done off the main trunk, with branches created for each release and for "major" subproject work. Emergency bug fixes are done on the corresponding release branch. 2) Each developer has their own branch which is merged to the main trunk to produce a release. 3) Other
Rocket science is more fun when you actually have rockets - US Navy ad
Our mainline code is the current release version. In our case, development is performed on a branch. Once the development has been completed and tested by the developers, it is merged onto the mainline for the next release, where the test team builds and tests the mainline code (which may contain merges from several other branches from the numerous developers. This way, during development, any emergency fixes to the release can be performed on the mainline code, and a new release or patch generated as needed.
Karl - WK5M PP-ASEL-IA (N43CS) PGP Key: 0xDB02E193 PGP Key Fingerprint: 8F06 5A2E 2735 892B 821C 871A 0411 94EA DB02 E193
-
I'm working on a new project of about 7 developers that may grow to 20 over the next few years. I want to know which branching approach is most favored for this size of a team/project. 1) All development is done off the main trunk, with branches created for each release and for "major" subproject work. Emergency bug fixes are done on the corresponding release branch. 2) Each developer has their own branch which is merged to the main trunk to produce a release. 3) Other
Rocket science is more fun when you actually have rockets - US Navy ad
with 3.7 developers: Almost always, development happens on the trunk. This way, integration is fast (and not breaking the build is everyones responsibility). Before a release, there is a "slowdown period", where only changes with local effect, bug fixes etc. are allowed on the trunk. Major changes would affect the release schedule. Basic "in house field testing" coems from the trunk, when things go really slow, it is branched. Branches are long-term bug fixed, but customers are encouraged to upgrade to new versions. Developer specific branches are created during the slowdown-period for major changes that DON'T go into the pending release, or if a major component's implementation needs to be replaced while to many people depend on that component. I encourage to keep developer branches short (<~1 month) before they are merge back into the trunk, but with varying success.
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
My first real C# project | Linkify!|FoldWithUs! | sighist