{"action":"created","issue":{"url":"https://api.github.com/repos/kaldi-asr/kaldi/issues/1179","repository_url":"https://api.github.com/repos/kaldi-asr/kaldi","labels_url":"https://api.github.com/repos/kaldi-asr/kaldi/issues/1179/labels{/name}","comments_url":"https://api.github.com/repos/kaldi-asr/kaldi/issues/1179/comments","events_url":"https://api.github.com/repos/kaldi-asr/kaldi/issues/1179/events","html_url":"https://github.com/kaldi-asr/kaldi/issues/1179","id":188359171,"number":1179,"title":"Versioning","user":{"login":"danpovey","id":3298747,"avatar_url":"https://avatars.githubusercontent.com/u/3298747?v=3","gravatar_id":"","url":"https://api.github.com/users/danpovey","html_url":"https://github.com/danpovey","followers_url":"https://api.github.com/users/danpovey/followers","following_url":"https://api.github.com/users/danpovey/following{/other_user}","gists_url":"https://api.github.com/users/danpovey/gists{/gist_id}","starred_url":"https://api.github.com/users/danpovey/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/danpovey/subscriptions","organizations_url":"https://api.github.com/users/danpovey/orgs","repos_url":"https://api.github.com/users/danpovey/repos","events_url":"https://api.github.com/users/danpovey/events{/privacy}","received_events_url":"https://api.github.com/users/danpovey/received_events","type":"User","site_admin":false},"labels":[{"id":492002441,"url":"https://api.github.com/repos/kaldi-asr/kaldi/labels/discussion","name":"discussion","color":"e99695","default":false}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":34,"created_at":"2016-11-09T21:39:08Z","updated_at":"2017-01-01T23:00:21Z","closed_at":null,"body":"People often ask about Kaldi versioning, but the continuous, many-threaded nature of Kaldi development makes it hard to meaningfully use a conventional version number.  People have also commented that it's a hassle that you cannot get the version number from compiled Kaldi binaries.\r\n\r\nThis 'issue' is to sketch out a possible solution for this, and to get comments.  This won't necessarily be done right away, or at all.\r\n\r\nFirstly, I don't propose to do conventional versioning where we release meaningfully numbered versions of Kaldi-- it's too much work to maintain.  But a reasonable compromise would be to just mark a new version number every week at a certain time.  The next commit after that time would [via a git-hook] be marked as that version, say version 1001, and commits after that [or commits derived from repositories whose git hash did not match the git hash of the clean version number] would be indicated as differing by a certain number of commits from the base version number, e.g. version 1001+15.  [We'd have to figure out precisely what git command to derive this information from.]  The idea is that you'd type, for instance,\r\n\r\n copy-feats --version\r\n\r\nand it would print out:\r\n  copy-feats  (Kaldi) version 1001, git hash ac48cfb\r\nor for a non-clean version:\r\n  copy-feats  (Kaldi) version 1001+2, git hash bcd8f92\r\nor if the src/ directory had non-checked-in changes to checked-in files [i.e. dirty index], it would print\r\n  copy-feats  (Kaldi) version 1001+2, git hash bcd8f92 [15 file changes not tracked]\r\nWe could also consider incorporating the date of compilation somehow.\r\n\r\nTo avoid triggering recompilation of all the object files, this information would have to be not in a globally accessible header, but one only visible to a .cc file.  For example, it could be put somewhere like base/version.h, which would only be included by a .cc file or files in base/.    This file would be recreated every time 'make' was run, by a script.  The script would read, say, 'src/.version', which would contain the version number and the git hash (e.g. \"1001 ac48cfb\"), and would then attempt to run git commands to figure out how far the git version was from the hash in src/.version, and similar information, and put the version string in base/version.h, as something like\r\n```\r\nstatic const char *version_string = \"version 1001, git hash ac48cfb\";\r\n```\r\nIt would write to a temporary file and only copy to base/version.h only if the contents had changed (to prevent triggering unnecessary recompilation).\r\nIn kaldi-error.h there would be a function declared\r\n```\r\nconst char *GetVersionString();\r\n```\r\nthat would return this string, for use elsewhere.\r\nThe code in util/parse-options.{h,cc} would be changed to support an extra standard option --version, and would modify the message printed in --help to include the version number.\r\n\r\nAn outstanding issue is how to have the version number printed out so that it appears in log files the right amount, but not too much.  One possibility is to modify the code that automatically prints out the command line used, to instead of printing, say,\r\n```\r\ncopy-matrix ark:- ark:-\r\n```\r\nso that it would print\r\n```\r\ncopy-matrix ark:- ark:-  # version 1001, git hash ac48cfb\r\n```\r\n(The hash mark means that if you copy and run that command line, it will still work).\r\n\r\nAnother possibility is to modify the MessageLogger:HandleMessage function so that if this is the first ever message printed by the program, you print a special LOG message with the version number info.  But I think the above method might be cleaner.\r\n\r\nAn issue with this is that every time the version string changes (which might be often), if the person had configured without the --shared option, re-linking would have to be done in every single bin/ directory.  That is inconvenient, and is the main drawback of this whole approach.  To remedy this we could switch to recommending use of the --shared option for default Kaldi installation (by changing /INSTALL and the order of suggested command lines in /src/configure).\r\n"},"comment":{"url":"https://api.github.com/repos/kaldi-asr/kaldi/issues/comments/269923549","html_url":"https://github.com/kaldi-asr/kaldi/issues/1179#issuecomment-269923549","issue_url":"https://api.github.com/repos/kaldi-asr/kaldi/issues/1179","id":269923549,"user":{"login":"danpovey","id":3298747,"avatar_url":"https://avatars.githubusercontent.com/u/3298747?v=3","gravatar_id":"","url":"https://api.github.com/users/danpovey","html_url":"https://github.com/danpovey","followers_url":"https://api.github.com/users/danpovey/followers","following_url":"https://api.github.com/users/danpovey/following{/other_user}","gists_url":"https://api.github.com/users/danpovey/gists{/gist_id}","starred_url":"https://api.github.com/users/danpovey/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/danpovey/subscriptions","organizations_url":"https://api.github.com/users/danpovey/orgs","repos_url":"https://api.github.com/users/danpovey/repos","events_url":"https://api.github.com/users/danpovey/events{/privacy}","received_events_url":"https://api.github.com/users/danpovey/received_events","type":"User","site_admin":false},"created_at":"2017-01-01T23:00:21Z","updated_at":"2017-01-01T23:00:21Z","body":"@dogancan, do you have any progress on this?  I know it's New Year's Day, but there are a few major changes that I don't want to check in before we've got the versioning squared away (your C++11 PR, and some fairly large changes to the nnet3 setup that I'm working on).\r\n"}}
{"actor":{"display_login":"danpovey"}}