This project has moved. For the latest updates, please go here.

Inconsistency in basic branch plan

Sep 8, 2010 at 9:33 PM

Hi,

in my opinion there is an inconsistency within the description of basic branch plan in different documents.

In HOL_Quick_Start_Basic_Branch_Plan_2010_v1.pdf it says that new releases will be merged from main to release (the picture also shows an arrow from main to release and the other way around). So there's only one release branch. Labeling is used to take control over different versions (Release 1.01, etc.)

While in TFS_Branching_Guide_Main_2010_v1.pdf it says:

Additional releases are supported by creating additional release branches for each product release. Each release branch is a child of MAIN and a peer to each other (e.g. release2.0 branch is peer to release3.0 and both are children of MAIN).

In the picture only an arrow is shown from main to release. Within this description there will be multiple release branches. No labeling is used.

In TFS_Branching_Guide_Scenarios_2010_v1.pdf the release branch hasn't been described at all. It does say that the Main and Dev branch have to be labeled, the other documents don't describe this.

I'm a bit confused.

Please help,

René

Developer
Sep 8, 2010 at 10:16 PM

René

Thanks for your feedback.

We recognize that there are some inconsistencies between the Main guidance document  TFS_Branching_Guide_Main_2010_v1.pdf  and some of the accompanying documents such as HOL_Quick_Start_Basic_Branch_Plan_2010_v1.pdf  or TFS_Branching_Guide_Scenarios_2010_v1.pdf. This is partly due to the fact that more time and focus was spent on the main document, especially in this latest release. The HOL and scenarios documents were written by different teams and originally published with Rangers Branching Guide II and were not as carefully reviewed for Branching Guide 2010 as I would have liked. We are planning another refresh of this guidance and plan to address all of these inconsistencies.

As for the specifics of your comments, it would be helpful if you would reference pages and diagrams so that I can be sure to correctly address your questions.

Regards,
Bill Heys
VS ALM Ranger

Sep 9, 2010 at 8:45 PM

Ok, I will use TFS_Branching_Guide_Main_2010_v1.pdf  then.

Inconsistencies figures:

TFS_Branching_Guide_Scenarios_2010_v1.pdf

Fig 1: doesn't show release branching

TFS_Branching_Guide_Main_2010_v1.pdf

Fig 1: the arrow on the right between main and release only points from release to main

HOL_Quick_Start_Basic_Branch_Plan_2010_v1.pdf

Fig 1: the arrow on the right between main and release points to both directions

I Inconsistenciesin the text:

I think I have described quite clear. Since you agree they aren't consistent and explained why I think it's a good idea to refresh the guidance. Maybe you could consider to remove TFS_Branching_Guide_Scenarios_2010_v1.pdf  from the guidance since it tries to address the same as TFS_Branching_Guide_Main_2010_v1.pdf.

Regards,

René

Developer
Sep 9, 2010 at 9:21 PM

René,

Thanks for your response. I can now respond more specifically to your questions.

1. With respect to the drawing for Fig. 1 in the Main Guide. This is how I prefer to show the *merge* direction between the RELEASE and MAIN branches.
If you look at PowerPoint slide 5 of the TFS Branching Guide - Diagrams 2010, you will see that we now label the arrow to better explain its purpose.
In our next refresh we will use this latest diagram in all of the document illustrations to be clearer and more consistent.

2. Fig. 1 in the HOL Quick Start Guide will change in the next refresh, as noted above.

3. Fig. 1 in the Branching Guide Scenarios document *intentionally* omits the release branching. In this scenario, for better or worse, we wanted to focus more on the detail and process for branching for a single development team. Here we wanted to show examples of labeling and merges over time. We chose to use a scenario for this purpose, rather than the main document so as to keep the main guidance more succinct and straight forward. Our goal is to use the scenarios to drill into more detail or to show additional variations beyond the branch plans presented in the Main Guidance. For example, in the next release, we may add a scenario to illustrate various options for sharing common code between projects. I welcome your feed back.

In addtion, I have found that many other branching and merging whitepapers tend not to separate the development side of the branching plan from the release side of the branching plan. There are times when the development branches are influenced by how an organization releases software. But often the development branches are intended to provide isolation during the development process while the release branches are intended to support software releases and sustained egineering. In other words, you may have a simpler development branch structure (to support a single team) coupled with a more complex release structure (to support multiple released versions with hotfix and service pack support). Conversely, there may be a need for multiple development teams coupled with a simpler release branch structure. The intent of the first scenario was to focus primarily on development. For that reason we omitted the release branches to help make the point that there can be this separation.

Thanks again for your feedback.

Regards,
Bill Heys
VS ALM Ranger

 

 

Sep 10, 2010 at 7:51 AM

Bill,

1. Clear.

2. Ok.

3. This is indeed the most confusion part. Your explanation helps a bit in understanding the relation of these documents. As I understand now the Main document and the Scenario describe branching from a different point of view. It's not clear to me how these views relate to each other. Is it a matrix?

 

                                Single Team        |      Conc hotfix, SP, VNext    |    Branching and Labeling scenario

Basic                            scenario 1.1                   scenario 1.2                            etc.

--------------------------------------------------------------------------------------------------------------------------------

Standard                     scenario 2.1                    etc.

--------------------------------------------------------------------------------------------------------------------------------

 Advanced                   etc,

--------------------------------------------------------------------------------------------------------------------------------

Mature

Developer
Sep 13, 2010 at 5:25 PM

René,

There is no formal or matrixed relationship between these two documents. It is likely that, in the future, we may add more scenarios on diifferent topics that don't necessarily relate to the branching plans described in the Main document. It is also possible that we may consolidate some scenarios into the Main document. If you feel that creating a matrix is helpful to you, you should feel free to do so. If you are finding confusion reading both the Main document and the Scenarios document, focus primarily on the Main document. My goal is to have a complete rewrite of the scenarios with the next version of the branching guidance. Thanks for your feedback. I hope to incorporate some of your suggestions in the next release.

Regards,
Bill Heys
VS ALM Ranger

Sep 14, 2010 at 1:28 PM

Thanks,

do you have any idea when the next release will be published?

Thanks,

René

Developer
Sep 14, 2010 at 1:50 PM

The Visual Studio ALM Rangers is in the process of planning and kicking off Rangers projects for FY11. We have not officially kicked off a project to publish the next version of branching guidance. I believe there is general agreement that we need to address many issues that have been raised in this forum and to add new topics (like feature teams, code sharing, etc) to the guidance. As you know I am pushing to make all the documents in the next release more internally consistent.

Unfortunately, I cannot commit to a publication release date at this time. We are very early in the planning process.

Regards,
Bill Heys
VS ALM Ranger

Sep 14, 2010 at 5:18 PM
Edited Sep 14, 2010 at 5:21 PM

Bill,

       Please don't take this the wrong way....but I'm shocked, SHOCKED,  that the rangers are in the early planning process for the next update to the branching guidance.

The TFS 2010 Branching guidance released (according to the file dates here on codeplex) on Jan 18, 2010. It's been 9 months since the release and you're just starting the planning process?!?! I thought you guys were following Agile over there....or atleast scrum. What kind of sprints do you have? 9 month sprints? Surely not....even the TFS Power tool team has committed to 4 month release cycles according to Brian Harry. Surely you guys can get another release out the door before Jan 1, 2011, right? That would be 1 release per year....a long time in todays world. And given the Dev11 beta 1 release in summer 2011...you guys will have to have something for that release when it's published right?

Keep up the great work...but please speed up the releases...I'd still love to get a branching guidance hands on labs using the feature builder stuff inside of VS 2010.

 

Allen.

Coordinator
Sep 14, 2010 at 5:36 PM

Hi Allen,

The Visual Studio ALM Rangers are focused on adoption blockers and most importantly bound by the prioritization of suggested projects by the internal (MSFT) and external (MVPs, etc.) Rangers.

The previous and latest submissions of adoption blocker project suggestions by the Rangers (internal + external) and Visual Studio ALM MVPs did not include the branching guidance. Thanks to the “agility” and more importantly the tenacity of the Rangers involved in the branching guidance, the refresh has made it back on the priority list and we are busy with the planning of a refresh and discussions on complex branching scenarios. You will notice activity on our blogs http://blogs.msdn.com/b/billheys and http://blogs.msdn.com/b/willy-peter_schaub, where we are discussing the refresh and pinging the field for feedback.

Regards

Willy-Peter Schaub

| Solution Architect | Visual Studio ALM Rangers | DevX Customer and Project Management |

| Tel. +1-604-247-6173 | Fax +1-604-682- 0282 | Blogs: http://blogs.msdn.com/b/willy-peter_schaub | IM: willy-peter.schaub@hotmail.com |

| Microsoft Canada Development Centre | 840 Cambie Street 3th Floor, Vancouver B.C. V6B 0B4 |

From: AllenFeinberg [mailto:notifications@codeplex.com]
Sent: Tuesday, September 14, 2010 10:19 AM
To: Willy-Peter Schaub
Subject: Re: Inconsistency in basic branch plan [TFSBranchingGuideIII:226529]

From: AllenFeinberg

Bill,

Please don't take this the wrong way....but I'm shocked, SHOCKED, that the rangers are in the "early planning process for the next update to the branching guidance".

The TFS 2010 Branching guidance released (according to the file dates here on codeplex) on Jan 18, 2010. It's been 9 months since the release and you're just starting the planning process?!?! I thought you guys were following Agile over there....or atleast scrum. What kind of sprints do you have? 9 month sprints? Surely not....even the TFS Power tool team has committed to 4 month release cycles according to Brian Harry. Surely you guys can get another release out the door before Jan 1, 2011, right?

Keep up the great work...but please speed up the releases...I'd still love to get a branching guidance hands on labs using the feature builder stuff inside of VS 2010.

Allen.

Read the full discussion online.

To add a post to this discussion, reply to this email (TFSBranchingGuideIII@discussions.codeplex.com)

To start a new discussion for this project, email TFSBranchingGuideIII@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com

Developer
Sep 14, 2010 at 5:45 PM

Allen,

To add to Willy's response. The VS ALM Rangers are primarily a volunteer group of people who are passionate about Visual Studio, Team Foundation Server, Application Lifecycle Managemement (ALM), etc.

We volunteer to contribute to Rangers projects. Most are doing this in our personal time, and are not directly compensated for our efforts.

The Rangers typically have a planning process at the beginning of a new fiscal year (July timeframe). It is clearly not intended to be an agile development process.

I, for one, have a full-time job. I certainly am not in a position to commit to quarterly or four-month releases.

As an aside, the Ranger guidance was first published in 2008 and refreshed in 2010. It was designed to replace, clarify, and build upon white papers that were published in 2005 or earlier. 

Regards,

Bill Heys
VS ALM Ranger
 

Sep 15, 2010 at 12:17 PM
Edited Sep 15, 2010 at 12:19 PM

Bill and Willy,

First of all let me appologize and put my tail between my legs....I'm sorry about the tone of my post. I had no idea that the MSFT employees who were rangers weren't full time employees being paid to do the ranger projects(MVPs and the field surely wouldn't be compensated)...but I thought you guys were....and given the volumes of guidance and tools the rangers release you surely should be.

I didn't realize this was a labour of love for you guys....an open source effort in many ways.

I can understand that it can be thankless at times to contribute (especially if you're not compensated) but the rangers work really does make adopting TFS much much easier and faster.

I hope your managers and executives at MS understand your value and can change your compensation plan around....something like Google's 20% time would really be quite reasonable given that you no doubt have full time jobs that consume 99% of your time.

I'll close out by saying: 1) I was wrong and ooops, 2) Thank you for your efforts!!!!!

+please continue to update the ranger projects faster so that we get uber projects and content all the time.

Sep 15, 2010 at 1:57 PM

Hi,

I was wandering if there isn't any general guidance about this topic, so not TFS specific.

Versioning and branching is a common thing to do, it can be done in any tool in my opinion.

A lot of people will have experience with branching and versioning, Microsoft for example.

If there is general guidance the Rangers Team could speed things up by referencing these general guidelines and then only describe how to implement common patterns with TFS.

But I don't know if any general guidance is available. Aren't there any college or university lessons\books available?

Thanks,

René  

Developer
Oct 19, 2010 at 11:04 PM

A key mission of the VS ALM Rangers is to provide guidance and best practices around the use of Microsoft tools, in this case VS Team Foundation Server. Many folks have found the branching guidance to be quite valuable when using other SCM tools. However, as a volunteer group, we simply do not have the time to create general guidelines and then extend these to TFS. I am sure if you do some research on SCM you will find lots more general guidance as well as guidance on other vendor's tools.

Regards,
Bill