I see there's some pretty sharp developers in here, so I have a question for You.
At my current job we use VS.Net and integrated VSS to manage our large web app. We do lots of releases to different clients, and with the addition of some new clients, we're trying to come up with a strategy to be able to do point releases, bugfixes, etc. for whomever at the drop of a hat.
I read the "Share, Pin and Branch to Create Service Pack Projects" (http://msdn.microsoft.com/library/en-us/guides/html/vstskshare_pin_and_branch_to_create_service_pack_projects.asp) article on MSDN, but I'm not sure if this fits exactly what we would need. I picture 3 different types of releases:
- Major releases (updates to large chunks of functionality, lots of new features, etc)
- Minor "point" releases (a particular piece of small new functionality, usually from a client request)
- Bugfix (urgent urgent gotta fix it now now now)
The problem with the MSDN article is they advocate driving your main project towards your next big release (i.e. you're on version 2.0 and you're working towards version 3.0), and if you need to do a bugfix you get all prior versions of files (using labels), and do a share to create a mirrored copy (i.e. 2.0.1) and just change your necessary files, do a release, and merge back in.
The problem is that we have multiple developers.. what if we've got a minor update (i.e. 2.1.0) being worked on as well as a major one (3.0) that overlaps the code of the minor update?
Here's what I'm envisioning, and you all can tell me how you do it, or what the flaw might be with this logic:
The main "branch" of the code would actually be used for the minor "point" releases. i.e. if the project stands at version 2.0 then the developer working towards version 2.1 would work off of the main project. If there is a bugfix prior to 2.1 being released, then we follow the "Share, Pin and Branch" article to create a bugfix, and then merge changes back in so that the bugfix will also be contained in the 2.1 release.
The big difference with us is when one of the developers starts working on major functionality that we won't want merged with the main branch until it's released. Say I'm working towards version 3.0 while the other developers are handling point releases and bugfixes. My idea is to do a "Share pin branch" on the main project to create a "3.0" project that I can develop and test on separately until we're ready to do the major release. Then we'd merge it back in with the main branch, and release from there.
So, do I have all my bases covered for the 3 release scenarios outlined above?
Thanks very much for your input.