Our situation is as follows, but I’m curious about this problem in any situation.
We have a framework consisting of 4 projects:
- beans
- util
- framework
- web
We also have modules that need a version and depend on a version of beans and util.
Finally we have a customer project that consists of a specific version of the core projects and one or more modules.
Is there a standard way to version these projects?
What seems simple to me is becoming really complicated as we try to deliver releases to QA and then manage our ongoing development with the maintenance of the release (release = tag and possible branch).
I kind of prefer the following:
1.2.0 – major and minor versions + release.
1.2.1 – next release
1.2.0_01 – bug fix in 1.2.0 release (branch)
etc.
Any ideas?
We use major.minor.bugfix. A major release only happens for huge changes. A minor release is called for when there is an API change. All other releases are bugfix releases. There’s definitely utility in having a build or revision number there too for troubleshooting, although if you’ve got really rigorous CM you might not need to include it.
Coordinating among the versions of all these projects can be done really well with help from tools like Apache Ivy or Maven. The build of one project, with its own version number, can involve the aggregation of specific versions of (the products of) other projects, and so your build files provide a strict mapping of versions from the bottom up. Save it all in [insert favorite version control tool here] and you have a nice history recorded.