#87 add recommendation regarding using git hash refs in modulemds
Closed: Fixed a year ago Opened 2 years ago by langdon.

We should add to the guidelines that people should, in general, not use git hash refs in their modulemds as it is a maintenance headache.

depends... in the current state of things, it should be opposite. Because every single day in master appear some new Requires/BuildRequires and so on. so tracking commits is way safer if you don't want to deal with huge amount of problems everytime someone pushes something to dist-git.

But generally I agree that packagers should use branches as refs

Ideally "arbitrary" branches that track upstream release schedules (like with modules, ahem).

Given the constraints of the traditional Fedora releases when it comes to dist-git branch names, perhaps we can find a way to recommend the use of named "module inclusion" tags instead?

For example, the system Python in Fedora 27 is 3.6, so all of the packages in the python3 and python3-ecosystem could have a "py3.6" tag that tracked the HEAD of their f27 branch. The python3:3.6 and python3-ecosystem:3.6 streams could then be defined as tracking those "py3.6" module inclusion tags, rather than any specific branch of the packages they need.

Once Fedora 28 happens, the "py3.6" tags in the various packages would switch over to the f28 branches, since the system Python will still be 3.6 at that point.

However, Fedora 29 will presumably be switching to Python 3.7, so the f29 branch would get a new py3.7 module inclusion tag, while the py3.6 tag would continue tracking the f28 branch.

If a Fedora release goes EOL before a module inclusion tag goes EOL, then the tag could be upgraded to be a new dist-git maintenance branch in the affected packages instead.

Metadata Update from @asamalik:
- Issue assigned to asamalik

a year ago

Metadata Update from @asamalik:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

a year ago

Login to comment on this ticket.