Reinhard Tartler <[email protected]> writes: > Måns, > > Generally, I really appreciate your eagerness for perfection, but at > this point, I really think you are overdoing it. Obviously, everying, > including version.sh can be improved. OTOH and espcially in open source > projects involving volunteers, workflows must also match to the way the > involved people work. > > As a compromise, let me bring up a variant of a proposal I made earlier > this month: > > - tag the branchpoint 'b0.7' (b == branchpoint) > - create a new branch 'release/0.7' > - commit the VERSION and RELEASE files to this branch > - tag the first release as 'v0.7' (v == version)
It would help if you could describe what you need for you packaging process. My best guess is that you need to override the version that would otherwise be reported with a debian-style version number, and that you want to build from a git repo so there has to be a way to override the "git describe" version. The version.sh script currently uses this priority: 1. VERSION file 2. git describe 3. UNKNOWN Would it work for you if we added another file searched after "git describe", in which we'd put the release version? The order would then be this: 1. VERSION 2. git describe 3. New file 4. UNKNOWN Name the new file whatever you like. -- Måns Rullgård [email protected] _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
