Re: [RFE] Add minimal universal release management capabilities to GIT

[nicolas.mailhot@laposte.net]

----- Mail original -----
De: "Jacob Keller" 

Hi Jacob,


> I think that this could easily be built by a separate script which provides git release command line and uses tags under the hood in a 
> well formed way.

True, the difficulty is not technical, the whole scheme is basic and KISS.

> I wouldn't say that the method outlined here works for all projects but I do agree it's fairly common and could work for many projects

I would be very surprised if there was a strong technical reason that stopped any project from adopting this scheme. Like I already wrote, Linux packaging tools work by converting public release naming to this scheme (with some additional twists, mostly there to help conversion of terminally broken, tooling-hostile and usually legacy projects, not worth the pain to import in new tooling).

> I think most large projects already use annotated tags and tho they have their own format it works pretty well. 

Raw tags are useless as release ids for tooling so everyone is forced to invent something else as soon as the project complexity passes a threshold (that's the point were there is no choice but to redefine tags, not the point were it starts being useful). I've already detailed why their laxity makes them useless.

> Showing a tool that could help projects create more standardized release tags would be helpful.
> 
> I think such a tool could already be built, scripted to create annotated tags with a well formed name. I don't think you necessarily
> need to have this in core git, tho I do see that your main goal is to piggyback on git itselfs popularity

I see little hope for such a tool. Reimplementation is too trivial and convention drift only starts to be acutely painful past a certain size. At that size you're almost certain to have already started using a custom implementation, with refactoring costs impeding switching to a generic tool.

Basically, it can only be done with a good probability of success by piggybacking on something that already federates a large number of Git users:
– Git itself, which is the correct most productive and least painful place for everyone involved
– one of the big Git-based forges, ie GitHub or GitLab. I'd expect it would be very tempting for one of those to make something that would effectively be a better Git than upstream Git, the usual embrace and extend effect.
– development language ecosystems (Python, Ruby, Go, etc). There are already many premises of such work since build automation needs ids that can be processed by tools.

The problem with letting forges or language ecosystems sort it is that you'll end up with functionally equivalent implementations, but divergent implementation details that end up wasting everyone's time. Like, decimal separator differences, deb vs rpm, car driving side, we humans managed to create the same clusterfuck time and time again. And much swearing every time you have a project that requires bridging those divergences.

It would be worth it if the divergence and competition helped new ground-breaking schemes to emerge but really, look at it, it's not rocket science. Everyone has been using about this scheme for decades with little changes. The remaining differences are slowly being eroded by the wish to automate everything.

Regards,

-- 
Nicolas Mailhot