maaku
commented
11 years ago I agree in principle, although pragmatically I think we need to recognize that it is Bitcoin which drives the development of the Freicoin client into the future. Aside from minor tweaks here and there, for the most part our task will be keeping the Freicoin client up-to-date with the latest changes being applied to the Bitcoin client. For this reason the intent was for Freicoin release numbers to track the bitcoind version associated with the release. Freicoin-0.0.1 was tied to bitcoind v0.7.1, and the upcoming Freicoin-0.0.2 release (currently being built) will be tied to the bitcoind v0.7.2 release. The “patch” numbers (-2, -3, -4, etc.) represented updates to the Freicoin client, typically minor, in-between bitcoind releases.
Now in hindsight I do agree that the decision to reset version numbers was poorly made. Bitcoin v0.8.0 is about to be released, and when we port that to Freicoin I would be for changing our version string to exactly match Bitcoin's. In principle I am also in favor of date-based version numbers with regular release cadence. But for as long as Freicoin exists as a fork of the more actively developed official Bitcoin client, I think it makes more sense to tie our version numbers to theirs, so that when a feature drops in Bitcoin mainline, people know where to look for that feature in Freicoin.
When user sees version number with two leading zeros, first thought: "It still very young, I should wait month or two before using it". This imprint can slow Freicoin adoption. Switching to date-based numbering system can resolve this issue. Ubuntu doing it, but not specifies a day (probably, to have possibility to move exact release date) By my opinion, 2012-12-31 looks more human-readable than 0.0.1-4 Protocol version anyway numbered according to upstream Bitcoin version.