On Thu, Nov 01 2018, Nicolas Mailhot wrote:
> git makes no provision for versioned release references. > > However, software projects need versioned releases. Software project > integrators need versionned releases. Security auditors need versioned > release. Software project users need versioned releases. > > Versioned releases are not the same thing as free-form tags. They have > semantics to allow deducing upgrade paths (usually, a form of semver). > They imply some form of API stability promise. They imply release > documentation completion. They're not just a random point in the project > history like tags are. > > This is why most git hosting sites provide a way to select versioned > releases, even if it's not a native git concept. And this way is clearly > separate and distinct from git tag selection. > > Unfortunately, since git makes no provision for versioned release > references, git hosting sites have to shove release refs into tag refs. > And it's a huge mess. > > Some put release ids in tags as-is, others add a v prefix, others a > version_ prefix, it's all hoster-specific, it's all inconsistent. It > ends up being inconsistent within projects, as they migrate from a > hoster to another, are mirrored from one hoster to another. It depends > on the habits of the person cutting a release, and the release manager > of a project can change over time. It ends up being inconsistent in > release archives, as the version munging can percolate in the archive > name and structure, or not, for mysterious heuristic reasons that change > over time. > > As a result, when assembling a project that uses other git repositories, > you spend more time checking repository by repository and version by > version how the version ref was mangled in a tag ref for this specific > (repo,version,date) tuple, than doing actual software dev and QA work. > > Please add a specific release reference to git, so software projects > that do versioned releases can use this ref object directly, without > needing to invent custom version rewriting rules to shove them in tags > while marking they are not just tags but release references. For both this and your other report, it would be helpful if you describe in concrete terms (with examples of git commands, or UI etc.) what git commands do now, what's wrong with it, and some sketch of what you expect an alternate interface to look like. As for this report: I know this area of git quite well, but I still have no idea quite what you're asking for. Do you just mean that we should have some other second-level namespace for tags, i.e. in addition to refs/tags/* we'd have refs/this-time-I-really-meant-it-tags/*., and e.g. linux.git and git.git v* tags would go into that, and have some "git tag --i-really-mean-it" interface? If we assume this is a good idea, how do you imagine this would work once you don't just have two levels (random labels v.s. "real" releases) but three or more (random labels v.s. "real" releases v.s. "LTS" releases, ....)?
