On Sun, Jun 19, 2011 at 18:42:19 (CEST), Måns Rullgård wrote: [...]
>>> 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 >> >> Now this puzzles me. >> >> You're essentially renaming VERSION to 'New file' > > No, the VERSION file, if present, will have exactly the same effect as > it currently does: overriding the git-based version tag. > >> and make 'git describe' override its contents. > > No, the new file will be a fallback for when git data is unavailable. > >> Obviously, the 'New file' can't go into master as it would make >> identifing the git version used to build the binaries impossible. > > Why? If built from a git repo, this file will never be used. Sorry, I wanted to write: VERSION file can't go to master. >> For packaging purposes, the new VERSION file could for example be >> copied over from 'New file' at build time to get the old behavior >> back. > > WTF? Your packaging repo could continue to carry a VERSION file just > like you're doing now. I don't see a difference. > > I'm suggesting to put the release version in this file, not VERSION, in > the master branch. Then builds from a tarball will use this version > while builds from a git repo will continue to use whatever "git describe" > spits out. I see. Let's call this new file 'LASTEST_RELEASE', then. Would 'VERSION' then go into the release branch, and thus, the tarballs? What about the release notes in the 'RELEASE' file, would you like to see it in 'master'? I think so, but keep in mind that it will be outdated rather quickly in a few months in non-release branches. > One side-effect of this will be that builds from a non-git tree will > identify as the latest release rather than UNKNOWN. I don't think > this is important. Well, it might for example in bugreports. There, we require people to state the version number used to build the binary. In case people build from a plain tarball instead of a git checkout, it makes it harder to distinguish if the tarball was rolled against some snapshot in master or a release tarball was taken. Think of platforms like win32, where there is no decent (native) git client available or the user prefers plain tarballs (which can be created on the fly in gitweb) over 'git clone'. I don't expect this situation to occur too often, but it still makes sense to keep in mind when reading bugreports. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
