branching publications

[Robert Lauriston]

Turns out that branching doesn't work the way I expected it to.

I figured that if I branch 1.0.1 from 1.0.0, and then branch 1.0.2 from 1.0.1, 1.0.2 would start out sharing all the topics from 1.0.1, but instead it shared all the topics from 1.0.0.

To get 1.0.2 to share all the topics of 1.0.1, I need to convert 1.0.1 to a main branch before branching 1.0.2.

Given this behavior, I don't think a branch command should appear in the popup menu for non-main branches.

[Rochelle F]

No, it must. There is a warning that a new branch comes from the main branch, and do you want to make the first branch off to be primary. If you go on a continuous line, this is fine. You don't need to keep 2 versions back. 

We found that branching is best for publications, because of the merge feature. It lets you see the difference in topics between two branches. Very important when you add new topics to a branch. 

But for topics, it is a bad idea. We had problems. When you branch a topic, it makes a new object. So if you need to make a change to the released topic that also affects the topic in progress, you have to do it twice. So we use the xinfo:version attribute inside a topic. It's like conditional text. One topic holds the content for all versions, and you pick what you want when you publish.

[Robert Lauriston]

Maybe your requirements are different from mine. I can't imagine why I would ever want to merge two branches.

I have no problem with topic branches. For example, my last release was 3.8.2. I'm currently working on the 3.8.3 branch of that publication.

For changes to existing features, I do a New Branch on the topic in 3.8.3 and label it 3.8.3. The changes appear in the 3.8.3 publication but not the 3.8.2 publication.

If I had to make a correction to both the 3.8.2 and 3.8.3 branches of the topic, I would have to do it twice, but that's very rare.

Paligo suggested using conditional text, but in a few years the source for some topics would be unmanageably complex.