Hello,
at our company we develop a software platform that spans from STM32 to WPF, REST services and OracleDB.
Currently we use this version numbering:
The database server has 2 digits, for example 7.7 Each client has 2 digits, for example 2.6
If we want to release AppClient 2.6 we will release as: 7.7.2.6.
Let's say a new server is released, 7.8, them we change a DLL and compile AppClient for 7.8.2.6
It may happens that version 7.8.2.6 and version 7.7.2.6 may have different source code because because the server library has changed the API
Then we release version 2.7 of AppClient: 7.8.2.7
And then we may release AppFirmware 1.3 that support both server, hence 7.8.1.3 and 7.8.1.3.
I think it's a big mess… we just moved to GIT from SVN One Flow. I want to change this confusing release version to something more aligned with sem ver. Does it make sense adding metadata to a build as server2.0: AppClient 1.3.0-srv.7.7.0 instead of 7.7.1.3 and 1.3.0 instead of 7.8 (we assume no data equals latest released server version). The problem is that AppFirmware 1.2.9 will be compiled against server 7.7 and not 7.8, we lost infos…
I mean this 'server dll' stuff seems just a 'deploy variable' but it can actually modify the code
Some suggestions on how to handle the branches on GIT?
Thanks
PS: don't forget the special case: old big client want support of AppClient 2.7 inside the old 7.7 DB hence AppClient 7.6.2.7
submitted by /u/edenroz
[link] [comments]
from Software Development – methodologies, techniques, and tools. Covering Agile, RUP, Waterfall + more! https://ift.tt/Enx736p