On Mon, May 5, 2014 at 3:58 PM, Joey Echeverria <[email protected]>wrote:
> On Mon, May 5, 2014 at 3:38 PM, Christopher <[email protected]> wrote: > > I elaborated above, but in short, all previous tags have indicated > > releases. This is standard to publish tags in SCM to denote a release. > > it's confusing to have a tag that does not denote a release. Further, > > having a version that is greater than the greatest approved release > > may mislead people who build from source to use the "latest", thinking > > it was approved and it wasn't. > > I agree that 1.4.6-eol is not a good name since it implies a 1.4.6 > release that never happened. > > I don't agree with the fact that tags are only used in SCM to denote a > release. I think that's the most common usage, but I've always viewed > a tag as any significant point on a branch that signifies not to > expect further changes. The places where those exist in most projects > is for releases and branches that have been EOLed. > > -Joey > .6 is part of what was causing me heartburn. I suppose another part is what the tag communicates. However, this can easily be solved w/ a section about tags on web site in the git docs. With an accompanying definition on our website, I would be ok simple tag like : 1.4-eol. The web site could define that tags matching this pattern reference unreleased commits for a branch on which we will no longer do releases..
