2

We currently have a big code base from which we can generate 5 differents softwares. The code base is composed of around 20 submodules which are used (or not) by each software.

Keeping a semver for each software will probably lead to a nightmare. We're gonna end with a ton of tags and branches on our git repository.

I'm thinking of giving a version number to the code base and whenever a software is released, it inherit of this number. Nevertheless , i see a big drawback with this method :
Let's say i'm at version 1.0.0 and releasing all my software, therefore they are all in version 1.0.0.
Later on, i release a big feature in the code base which now is in version 1.1.0.
=> Software 1,2 and 3 use this feature and are released in 1.1.0.
=> Software 4 and 5 are still 1.0.0.

Now , i need to fix a small bug in the code base for all the softwares. The code base version is now 1.1.1. I release all softwares :
=> Softwares 1 to 5 are in 1.1.1 .
That where i'm not so sure of this method because Software 4 jump from 1.0.0 to 1.1.1 just for a minor fix.

I'm also considering having a semver for the code base and a more user friendly number for each software which will hide those awkward jump in version number :

-------------------------------------------------------  
| codebase  | Software 1  | Software 2  | Software 2  |  
-------------------------------------------------------  
| 1.0.0     |    2018.1   |    2018.1   |   2018.1    |  
| 1.1.0     |    2018.2   |    -        |     -       |  
| 1.1.1     |    2018.3   |    -        |   2018.2    |  

Is there a simpler way of handling this ?

  • Is this a software product line where "codebase" represents your shared assets and "Software 1", "Software 2", and so on are products? – Thomas Owens Jul 13 '18 at 12:54
  • 1
    why not also develop the fix in a 1.0.1 for software 4 ? It could even be develop in the branch of 1.1 and then merge to the 1.1.1 for others (specially with git). – Walfrat Jul 13 '18 at 12:58
  • @ThomasOwens Softwares share some functionalities like user management and assests like icons but are totally different product in the end. For exemple i can produce a video player with ui or a deamon handling data over network. I guess we can call it a software product line. – grunk Jul 13 '18 at 13:03
  • @Walfrat it could be a solution but i see a big risk to forget to merge a commit in one of the multiple branch. :/ – grunk Jul 13 '18 at 13:05
  • Are there dependencies between the products? Do you know them? – max630 Jul 13 '18 at 13:16
5

You have listed 2 broad problem areas. 1) Repository versioning. 2) (not so much of s problem) translation of version numbers which sometimes is useful for layman end users.

First problem can be greatly simplified by refactoring the codebase comprised of git submodules into a separate git repositories.

You may call them libraries but they are individual projects which has its own lifecycle. This is because say a user module - which is now a repo - needs changes, well this is the lifecycle of user module so it can be tagged and follow semantic versioning.

Individual softwares might have some code but at the minimum they have build systems and most significantly these projects actually make a release and deployment for end users ( I am now assuming). Hence these software 1, 2, 3.. each should also be a separate repository and its own versioning. A fine distinction I want to add here is about distribution. If a same "software 1" produces several distribution e.g iOS, Android distributions from same codebase you should not create a separate repository for this. In other words don't call software 1 as iOS and software 2 as Android if you business logic and features come from same codebase and it's just how you package it.

Having said this you need to establish clear boundaries between the repositories. This can be done using defining interfaces and making sure these projects share finished fully QAed artifacts.

Sometime developers tend to add multiple projects into a single repository (and then use git modules) to bring each of them in their favorite IDE which seems convenient at the time but gives rise to the problem you are dealing with.

In order to deal with the separation fatigue you can use a good CI/CD pipeline and automate them. Your library distribution can produce source maps or ability to attach sources to the compiled code that is shared so that you can develop "software 1" (we call it "Application" BTW).

But if separate repository cause more work than the conplexiety you identified you take on that versioning complexity. Remember the benefits of smaller manageable projects are just too many to list here versus a large monolithic project. You may fell or start to rethink why you have got submodules in the first place.as you realise the benefit analysis.

The second problem is just versioning transformation. 1.0.0 to 2018.1. you could write a small deterministic function and use it everywhere.

Long post but semantic versioning is just more than numbers.

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.