1

So we have a code base that gradle builds into 3 different targets for 3 different clients that are from a business perspective completely separate. To simplify our release workflow, we have opted to keep the same versioning for all targets as less than 5% of changes are client-specific and we'd much rather keep track of one version than 3.

Let's say we make a change in the code base that only affects target A and released it for target A.

We have two options for B and C:

  1. Simply skip version, don't talk about it in release notes, it doesn't exist.
    • It doesn't look very nice...
    • I wonder if clients might might perceive this negatively
  2. Release version for all three targets:
    • Release notes will have something very generic (that is also a lie): "fixes and improvements"
  3. Try to bundle changes so there's always something to talk about in releases
    • For example, if I make a change that is A-specific, I bundle with it a feature or bug fix that is not target-specific so that the release is a legitimate update for all targets.
  4. Split the versioning into 3 and keep track of which version in A, B and C correspond to each other
    • Last resort

Any suggestions?

Update: For business reasons, we can't talk about one client with the other clients because from a business perspective, the products are actually different.

5
  • Is it important to hide this A specific change in release notes for B and C? Sep 27, 2017 at 8:01
  • 4
    I'm voting to close this question as off-topic because it is a sales & marketing related question; not a software engineering one.
    – David Arno
    Sep 27, 2017 at 8:25
  • 1
    @DavidArno Not completely. It's a general bad practice to do confusing versioning. It's also a bad practice to have customer specific code in your common code base and to lie in the release notes. Sep 27, 2017 at 8:34
  • First of all, the sales and marketing stackexchange is still in Area51. Secondly, I highly doubt that sales and marketing people would know much about the topic of software versioning. Third, whether or not this question fits here really depends on how you define Software Engineering. Ian Sommerville defines it as "an engineering discipline that is concerned with all aspects of software production". That includes versioning and distribution. I disagree that this is a "Sales and Marketing" question, at best, this is an inter-disciplinary topic.
    – Jbezos
    Sep 27, 2017 at 10:36
  • One point of confusion: Is the A specific change actually ever delivered to B & C?
    – JimmyJames
    Sep 27, 2017 at 16:13

3 Answers 3

2

It's fine to skip version numbers.

  • Java went from version 1.4 directly to 5.
  • Angular went from version 2 directly to 4.

Just never go back or do confusing versioning like Microsoft did with Windows (3.1, 95, 98, 2000, ME, XP, Vista, 7, 8, 10)

To avoid your current problem:

  • Never have client specific code. Instead take a feature approach. If client A needs a special feature X and client B needs feature Y, you can mention bug fixes to feature X without having to disclose information about client A to client B.
  • If you cannot avoid client specific code, try to externalise it into a external library (DLL/jar). If your client specific code needs fixes or enhancements you can update your library without the potential risk of affecting other clients.

Do not lie to your customers. If they ever experience a problem for code that was meant for another customer, they might find out you lied to them and this can have consequences (even legal ones) for you business.

5

Why not just be honest about it? Just put a general disclaimer somewhere:

Some release contain only client-specific fixes, so not every release is made to every client.

2
  • That would make sense usually except we can't do that for business reasons.
    – Jbezos
    Sep 27, 2017 at 8:03
  • 5
    In which case, this is a sales and marketing question, not a software engineering one. Sep 27, 2017 at 8:06
2

Customers usually don't care much about release numbers accept for getting the latest, but you do. Therefore it is ok to skip release numbers for the customers who are not affected by the "skipped" release.

For the same reason you could simply change your release number sheme from consecutive numbers to month/year like we have for some linux distros. This would avoid discussions with marketing...

1
  • This makes a lot of sense. I think I'll go with your first suggestion and just skip the releases.
    – Jbezos
    Sep 27, 2017 at 8:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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