ffmpeg: Switch to revision based versioning, not release #479
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Discussing the proposed ffmpeg changes (#477) on slack brought up an issue with the current ffmpeg versioning.
If a builder downloads the 3.0-xbmc ffmpeg source tarball (as I did at the end of March) to their
sources
cache they won't ever download the 3.0-xbmc ffmpeg source tarball again even if is updated with new commits (unless they delete their existing tarball).The current 3.0-xbmc ffmpeg version is now 3.0.2, which is 33 commits ahead of the 3.0.1 version I downloaded in March.
Someone building master who has never downloaded the ffmpeg tarball will build with the latest 3.0-xbmc (ie. 3.0.2, plus a few more commits) while I will continue building with 3.0.1, blissfully ignorant of any new fixes (or new bugs).
This clearly isn't a good situation, as we should all be building the same source code, hence this switch to hash based versioning.