1

I'm looking for a way to pithily define a abstract term that declares all versions that a bug effects, or that a feature behaved a certain way. For example, feature X worked way Y in versions 1.3 to 1.5, but then they changed it. I thought of calling 1.3 to 1.5 a "version span", but wondered if there was some common terminology that I would not have to explain all the time to everyone?

This could get more complicated for bug fixes that are done on different minor versions of multiple major versions. For example, a bug that was first introduced in 1.4 and fixed in versions 1.6 and 2.2. 2.1 also exhibits the bug because 2.1 branched from 1.4. So now you have a "version span" of 1.4 - 1.6 & 2.1 and all their patch versions and build versions etc.

  • You already nailed why there's no term, it would break on so many way that the usual method is what you did here from verzion b to c, and from d to eand 'list of single version affected'. I'm quite unsure this has to do with devops at all... – Tensibai May 8 '18 at 10:18
  • @jim are you looking for release notes of different versions? – 030 May 8 '18 at 20:17
  • @030 Instead of having to look through release notes this would be a table of features mapped to versions. Release notes typically have "bugs not fixed" but release notes never show bugs not yet found. My customer has multiple variants/branches of systems deployed all over the world, and wants a quick and easy way to know which variants and deployments have which features and bugs. – Jim May 8 '18 at 21:21
4

I have never heard of a common name for what you describe; and rarely, if ever, have I seen a notation where someone references to something which has a "begin" and "end" version. It just is not that applicable in a general fashion; this is probably why there is no such name. Also changelogs usually don't contain this information except for extremely bad breaks that need some kind of notice about which span(sic) of versions one should rather stay clear of.

The closest you could get to a common name (popularized by Jira, for example) is probably to call 1.3 in your example the "affected version", and 1.5 the "fixed version"; possibly allowing multiple values there. But they also have no name for the span as an entity.

Note that it is not really a problem if you have multiple old maintenance releases like you are describing. Those would just lead to multiple spans distributed over the branches.

Regarding your edit:

Instead of having to look through release notes this would be a table of features mapped to versions. Release notes typically have "bugs not fixed" but release notes never show bugs not yet found. My customer has multiple variants/branches of systems deployed all over the world, and wants a quick and easy way to know which variants and deployments have which features and bugs.

Been there done that. You are doing well to approach this with care, it can really "explode" after a while. If you are using a tool like Jira, you should really find a field for each issue which allows you to mention releases related to the issue. If you decide do go manually, just list your version ranges in whatever format seems right to you.

I would not bother with finding a name for a range of versions, but just call them "affected versions".

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.