Creating Condition Tags for Versions

[schultza]

We are implementing Flare, and some of the condition tags we are creating represent different releases of our software (because we can't just be sensible and maintain a single code line).

For example, I have a Daylight Saving Checklist that I have 5 targets for (each corresponding to a different version). I have a number of topics in which there are single lines of text that pertain to one of these versions, and hence they are conditioned. This is easy enough, because when I set up my targets, I am excluding the versions that don't apply to each target.

My question...what should I do when I have text/topics that applies to say, just versions 3-5? Currently I am selecting those elements and applying all 3 version tags. However, this means when our next release comes out I will have to go through everything I have conditioned and, if necessary, apply the new tag for version 6. And go through my 5 targets (and new 6th target) and make sure the new condition is excluded where needed.

Is this the best method/route of doing things?

[Andrew]

We have the same problem (supporting multiple releases), but we rarely tag at the release level. Instead of tagging at the release level, we typically tag at the feature level. For us, this is not too hard, as our features are usually fairly well-defined (not in the docu; they are all over the place there, but in terms of development and which versions have which features, and knowing what counts as a "feature" when we are doing the initial writing). It's actually very little extra work, and it gives us a huge amount of additional power: those features that "yes, we released that" (only to later find that they didn't) -- or vice-versa -- we just click a check box in our target conditions and we are all set.

I'm not sure if that would work for your team.

[schultza]

Does this mean you have a lot of tags then? For example, in the release notes I am currently documenting, there are 42 new features. That would equate to 42 condition tags vs. just 1 condition tag for a new version.

[Andrew]

Yes, we do. We create a new Condition Tag Set for each release. While we are more likely to have 15-25 features in a release, we release 3-4 times per year. Also, our versions do eventually fall out of support, so the plan is, at some point, we will remove the old unneeded conditions. Neither method is perfect.

[schultza]

Thanks, Andrew! Your input has been very helpful and reassuring!

[i-tietz]

Yes, we do. We create a new Condition Tag Set for each release. While we are more likely to have 15-25 features in a release, we release 3-4 times per year. Also, our versions do eventually fall out of support, so the plan is, at some point, we will remove the old unneeded conditions. Neither method is perfect.

Featurewise conditioning - this is also the recommended way to work in "agile" projects - saves nerves and time as well as it prevents errors.

[schultza]

Can you give me some examples of what you name your conditions for features?

I've thought on this a little bit more, and am confused how this works. For example, I can understand initially having a condition for "New Logon Screen." But then what happens if in Software Update 1 there is a small tweak to this screen. Would you then create another condition like "Logon Screen SU1 Tweak"? And so on?

[i-tietz]

I don't quite get what you mean: The new logon screen is part of the software already and now it has been developed even further?
Then I wouldn't have the condition "new logon screen" anymore - I'd have deleted the condition itself and all the condition tags in the topics or in the file structure, ideally using a projectwide find&replace with regular expressions. So I could now call the new feature "tweak logon screen".
Or do you have afeature that comes in more than one step? Then maybe numbering them would be possible?

In fact in my case it could be even more comfortable: We have a database for enhancement requests and errors. Each error/enhancement document has a unique number. For small features it's usually one of those documents and I could use its number for the condition. For bigger features we have subject names, e.g. "e-letter". I would start with a condition "eletter0" just in case development splits it up and won't implement it all in one go.
Maybe you have sth like that, too?

And don't forget: Sometimes you would have to change text that already exists in current versions. Means: you don't just add something. In that case you would need two conditions: e.g. eletter0yes and eletter0no. You copy the relevant text/topic and apply those two conditions, then you change the bit for eletter0yes.

[schultza]

Thanks! That makes a little more sense.

Yes, we do track features, enhancements, and defects using numbers (it's too bad my company is still trying to merge us all onto TFS; we currently use 3 different systems of numbers for tracking this stuff, depending on what solution/application we work with).

But that does make sense. If I have a User Story 10 to add a new feature in this release, we would create a condition US10. If we fix something later on for that feature in Defect 1012, then I would create a condition DE1012 to work with added/deleted text in my topic.

[Andrew]

We used to use feature numbers (our features were typically a 5-digit number, such as 54985). However, when we moved to agile development, and features were stories (or groups of stories), we changed to naming the conditions something like: DoNotSendFailedCreditCardsToAROption It's longer and harder to read, but unique.

[i-tietz]

The handling of the conditional text/topics/folders when you delete a condition could be more comfortable - e.g. just like it is in FrameMaker (FM). If I delete a condition, FM asks me what to do with the conditional text: I could delete the text or leave it and just get rid of the condition ...
When you do that sort of thing in Flare you have to do some refinishing work to get rid of the condition in the rest of the project. The Flare report feature helps a bit, but nevertheless it's an effort.

[Andrew]

The handling of the conditional text/topics/folders when you delete a condition could be more comfortable - e.g. just like it is in FrameMaker (FM). If I delete a condition, FM asks me what to do with the conditional text: I could delete the text or leave it and just get rid of the condition ...
When you do that sort of thing in Flare you have to do some refinishing work to get rid of the condition in the rest of the project. The Flare report feature helps a bit, but nevertheless it's an effort.

Yep. It's another of the issues in Flare with not automatically updating links for stuff that is in the Project Explorer (like the fact that renaming variable groups doesn't rename them everywhere in your project).