I'm still pretty new to git, so my question lies somewhere between "is this even possible?" and "where would I even begin to look for the answer to this?"
I have inherited a code base which is all stored in one git/GitHub repository, and I need to establish a version numbering scheme. I've already determined that the best approach is to use git tag and Semantic Versioning to establish a 3-digit version number like v1.3.4, and also to use the git describe command to have extra info on there. And that's all great.
The trouble is that this is really a software package with two different components, and later on we may need to ship those components individually. So I'm trying to figure out a good version numbering scheme to handle that, and see if I can make this version numbering scheme work within the git/GitHub infrastructure.
So let's pretend that the overall application is a fishing pole, which has a rod and a reel. What I'd like to do is be able to version all of those individually. So we could have a release:
- FishingPole v1.2.1, consisting of
- FishingRod v1.0.1
- FishingReel v1.2.0
Later on, if we make a change to FishingReel, we bump its revision and naturally bump the top-level revision too, but FishingRod doesn't change:
- FishingPole v1.2.2, consisting of
- FishingRod v1.0.1
- FishingReel v1.2.1
The trouble is that it appears to me that a git tag can only apply to the repository as a whole. As a related problem, it seems like there wouldn't be any way to make git describe give a description of a component (FishingRod or FishingReel), but rather it would only describe the repository as a whole (it would only describe FishingPole). Is there any sensible way to make this scheme work with git tag and git describe if all these pieces exist in the same repository?