Build versioning for Solution/Projects
-
The solution has multiple projects(Call it modules) each running on it's own dev-cycle/version sequence. Module-A Build 1.0.2 Module-B Build 2.0.4 Module-C Build 1.5.3 ------------------------ Solution Build __? Like this, each managed by separate teams. But as a solution when it goes to the customer, Can I maintain it like 1.0.0 , 1.0.1 irrespective of what the modules versions are inside?
-
The solution has multiple projects(Call it modules) each running on it's own dev-cycle/version sequence. Module-A Build 1.0.2 Module-B Build 2.0.4 Module-C Build 1.5.3 ------------------------ Solution Build __? Like this, each managed by separate teams. But as a solution when it goes to the customer, Can I maintain it like 1.0.0 , 1.0.1 irrespective of what the modules versions are inside?
Why add an extra level of translation, so that when a customer contacts you with an issue on build 1.1 you have to pull out the spreadsheet to discover it's built 1.1.45? Just think of all those extra possible 2 minutes adding or more up over the year when supporting the product. Then think of those times when the spreadsheet is corrupted or out of date. Heck why bother with a spreadsheet? Why not create an app just to convert the customer's version number to a useful version number that you can track to a build? I would not go down that route - there again I am not in sales "An added feature to our product is that we only use version numbers that are aesthetically pleasing, we are sure because of this your users will find it highly intuitive and easy to use!" (apologies for the sarcasm at the end)
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
-
The solution has multiple projects(Call it modules) each running on it's own dev-cycle/version sequence. Module-A Build 1.0.2 Module-B Build 2.0.4 Module-C Build 1.5.3 ------------------------ Solution Build __? Like this, each managed by separate teams. But as a solution when it goes to the customer, Can I maintain it like 1.0.0 , 1.0.1 irrespective of what the modules versions are inside?
It's a situation I faced at a work-place with a Ruby MicroService-based API. The individual microservices and dependent library gems could have independent versions, then the whole delivery to a customer needed a version. Ultimately, we semantically versioned the 'package'/'deliverable' or in your case 'solution' much the same way an individual component was versioned ie - if ANY subcomponent was breaking, the MAJOR version was changed and so forth The only issue with all of this we found was we needed to keep a 'store'/database of package/deliverable/solution version vs sub-components delivered, to make diagnostics etc easier
-
The solution has multiple projects(Call it modules) each running on it's own dev-cycle/version sequence. Module-A Build 1.0.2 Module-B Build 2.0.4 Module-C Build 1.5.3 ------------------------ Solution Build __? Like this, each managed by separate teams. But as a solution when it goes to the customer, Can I maintain it like 1.0.0 , 1.0.1 irrespective of what the modules versions are inside?
The VERSION resource has room for both file version and product version.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
The VERSION resource has room for both file version and product version.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
Exactly the approach we use in our products. File version is used by each developer however they like. Product version is handled by our automated build, and is identical across all build outputs (EXE's, DLL's, etc). The semi-neat trick behind all of this is the fact that our product is a mix of C#/.NET and C++/MFC. The build process edits a
*.hfile for the C++ code and a*.csfile for the C# to have the same build information (product version, build date, optional comment).Software Zen:
delete this;