Configuration management and version control are great and useful topics, and very important in the world of software. To that end discussion on these topics is good and useful. But please let's all try to keep it professional and not personal.
The open source development environment can range from very tightly controlled and well organized (e.g. a major project with a large number of players) to pretty much the equivalent of the Wild West (e.g. smaller projects with few or no rules, controls or process and a small number of developers).
Historically, the development of Thetis (and PowerSDR mRX before it) has been very casual, has not made use of a common repository, and has involved very few dev's, none of whom has chosen to use any sort of formal configuration management tools or processes. Just throwing it into Github doesn't count. However, lately, Richie's use of Git to track issues is a move in a more formal direction, which IMHO is long overdue.
Also historically, while/when there is a primary active developer, that person has been the de facto lead and people have generally chosen to work through that person. For instance, during the development of PowerSDR mRX, Doug (W5WC) was that person. "Official" (whatever that term is worth) releases came though him and were published on the TAPR Git repo. Same for early Thetis development. When Richie started to make major contributions the de facto leadership went to him. Richie did not have access to the TAPR repo and decided to stand up his own Git repo. Richie was moving fast and furiously enough that Doug was very happy with that arrangement.
In a perfect world everyone involved would be working out of a common Git repository and would be responsible for their own builds/branches within that repository. There would need to be some agreement and cooperation among dev's as to the organization and processes used in that common repository. The major stumbling block to achieving this is developer knowledge of modern software development processes and configuration control systems. I.e. knowledge of how to use Github and all of its features. Without wanting to throw anyone under a bus, it would appear that few, if any, contributors, have a lot of experience with formal software development environments and processes. This makes it difficult to achieve such a utopian goal.
Versioning schemes
Leaving aside the promise of Github software utopias, having an agreed upon versioning system is an easily attainable goal. For those who are not familiar with the 4 digit versioning scheme, it generally goes like this:
major.minor.maintenance.build
One can argue for days over what represents major or minor releases. But what is clear is that neither of these numbers should advance unless there is additional functionality added. These should not advance for mere bug fixes.
Maintenance releases are clear: any collection of bug fixes = an increment in the maintenance version digit.
IMHO build should always = 0 for "official" releases. Build numbers other than zero are to denote alpha and beta releases.
The effect of multiple repositories on versioning
If all versions came from the same repo this challenge would not exist. Unless and until that utopian vision happens, it would be very nice from a user perspective to know whose repository the build was coming from. The reason this is critically important from a user perspective is because otherwise how is anyone able to keep track of what they are running and compare notes with others? Every developer does tend to increment version numbers on their own. But when you have 3 or 4 folks doing this it can get very confusing for the users, and not much less confusing for other developers.
To that end Mark's comments are very compelling. Not from any philosophical, moral or ethical standpoint, but rather, and much more importantly, so that we can all simply keep track of what we are downloading and running more easily.
Unless and until all builds come from the same repo, IMHO, and FWIW, versioning should work as follows:
1.
Never add a date to the build on the title bar.
Always increment the build digit.
2.
Always add the repository name to the title bar.
However, all this brouhaha may blow over in the short term. With Richie becoming active again, even at the relaxed pace your are promising us, Richie
, I suspect your level of productivity will quickly act to absorb all other developments and for all intents and purposes nearly 100% of us will be running your builds exclusively.
Nevertheless, during the lulls in development which happen periodically, when a few hobbyists are adding things they like somewhat randomly, perhaps the discussion of versioning schemes might be revisited.