Closed jrbriggs closed 5 years ago
derrickstolee
commented
5 years ago I like these version numbers. For tags, can we create them in response to a build that we plan to release?
That is, create v19.08.157.1 as part of the release pipeline from releases/19.08.157?
jrbriggs
commented
5 years ago Yeah my feeling is tags are used more to mark where a release occurred, and not as a source for a build, so I didn't put a lot of thought into what a build number from a tag would look like. IMO we would re-run the build on the releases/19.08.157 again, it would increment the counter, and we would get a new tag pointing to the same commit if nothing else had changed.
I'll figure out something for tags for the sake of completeness but I don't think it's an important scenario to nail.
jrbriggs
commented
5 years ago I made the simplifying assumption to treat a manual build of a tag identically to a typical branch CI.
There is a hole in this versioning story where a CI build out for two branches could be stamped with identical versions. I'm not super concerned about that right now since the only ones that will ever make it into the wild will be properly versioned and I'm not inclined to complicate this further just so the first ci on features/abc has a different version number than the first ci on features/def if they first run on the same day.
wilbaker
commented
5 years ago There is a hole in this versioning story where a CI build out for two branches could be stamped with identical versions.
I don't quite follow how this could happen. If the manual build is kicked off using the pipeline, would counter give it a new value?
It would be ideal if the versioning scheme gave a better indication of the time of release and the milestone associated with the bits.
I propose the following, where {build} = counter(SourceRef, 0)