2013/8/7 Benjamin Hindman <[email protected]>: > We've been tagging release candidates as a.b.c-rcN. Once a > release is voted on, we create an a.b.c tag. IIUC your script > can use this instead of an a.b.x branch. We prefer tags to > branches for their immutable semantics (assuming you don't > delete and re-push a tag, which we've been doing *only before > announcing* a tag, but can stop if your script expects > otherwise).
This will indeed work for building specific revisions. I suppose in this case, the script could simple build the target with the highest RC number if there is no plain a.b.c tag. > As for building a package for the master branch, I'd like to > propose a versioning scheme that includes the date, i.e., > 0.14.0-20130806 (a.b.c-YYYYMMDD). The date is okay, too. But how will the script determine that master is supposed to be called 0.14.0? Does it look at the most recent RC and increment by one in the minor version field? Seems sketch to me... This is the motivation for having branches, which can track a moving target like the next release, and give one a way to communicate to the script that it should have a special name. In lieu of such a convention, I think it is only reasonable that master be given version 9999. -- Jason Dusek pgp // solidsnack // C1EBC57DC55144F35460C8DF1FD4C6C1FED18A2B
