Versioning convention for Bitcoin Core #9653
Comments
Feel free to discuss this. I'm mildly in favor of the idea of dropping the first number (I already do that in my head), but it's certainly not going to change in the timespan until 0.14. |
|
IMO the opposite of mindset 1 is true if anything: Bitcoin is in production use, even if implementations are still immature. I think we have a long way to go before 1.0 would be a good idea... At the very least, I think we should have the code modular first so each component can get its own version at an appropriate time. |
|
This has been discussed many times before. I am in favor of simply dropping the |
|
I am of the opinion that moving from beta to 'production' - from 0.XX to X.XX - is inappropriate at this time. This transition can be used at a future point to indicate certain components are 'finalized' or the software has reached a certain, as-of-yet-unreached maturity state. |
|
I think this is not so important to bother with this |
Opinions differ greatly on this. Some people are of the opinion that bitcoin is pretty much finalized, and just polishing remains. It is used in production after all and is critical to quite a few people. Others think the largest changes are still ahead of us. There's no point in having arguments about that because the future is, as always, unsure. This is a new field and no one is setting goalposts in cryptocurrency. So no, it's extremely unlikely that 0.x to 1.x will be used to signal anything. Just search the issues and mailing list a bit, this has come up many times before, with people asking as far back as in 2011 when the version will finally go to 1.x. |
|
Yea, let's not make a big deal out of version numbers... They're just numbers. Hell, if we don't have anything else I'd recommend releases just take the number from the number of commits in them :p.
Indeed, I've been colloquially referring to versions without the "0." for a while so have no problem making that change... Really my vote is @laanwj rolls a dice and picks something :).
…On January 31, 2017 6:54:52 AM EST, "Wladimir J. van der Laan" ***@***.***> wrote:
> I am of the opinion that moving from beta to 'production' - from 0.XX
to X.XX - is inappropriate at this time. This transition can be used at
a future point to indicate certain components are 'finalized' or the
software has reached a certain, as-of-yet-unreached maturity state.
Opinions differ greatly on this. Some people are of the opinion that
bitcoin is pretty much finalized, and just polishing remains. It is
used in production after all and is critical to quite a few people.
Others think the largest changes are still ahead of us. There's no
point in having arguments about that because the future is, as always,
unsure. This is a new field and no one is setting goalposts in
cryptocurrency.
So no, it's extremely unlikely that 0.x to 1.x will be used to signal
anything. Just search the issues and mailing list a bit, this has come
up many times before, with people asking as far back as in 2011 when
the version will finally go to 1.x.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
#9653 (comment)
|
|
I apologize for dragging a dead horse out of its grave, so to say. I really should learn to search better, but the tools to do so aren't super obvious to me. My personal issue with this whole thing is that
|
|
@laanwj I think approaching this so casually misses my point : there's an opportunity to utilize the transition from o.XX to X.XX as a branding/external command event. Having a natural transitive stage as this is a nice-to-have, and should not be discarded lightly. |
|
**external comment event |
|
@Leviathn, I doubt we can ever agree on when to name the version 1.0.0
instead of 0.XX.XX. Right now Bitcoin Core is doing a rolling release
about every 6 months (and minor releases whenever applicable). The
version number pretty much only tells in what order the releases were
made.
The difficulty to decide when to tag it version 1.0.0 arises when you
realize that Bitcoin Core is pretty much a massive bundle of different
modules (c.f. the folders in /src or the slide at
https://youtu.be/8BLWUUPfh2Q?t=2h46m19s). And even if you could decide
for a single of those modules that it reached version 1.0.0, we can
just put "Bitcoin Core 21.0.0 comes bundled with a stable release of
Core Wallet 1.0.0" in the release notes, even though other parts of
the software may be less mature than most stable part at that time.
Lets jut get rid of the idea that a semi-arbitrary number that happens
to denote the version of a Bitcoin Core release implies that the
maturity of the software or even of the whole Bitcoin network is
reached. Otherwise, when version 1.0.0 means "stable", does 2.0.0 mean
"more stable"? If so, we can just use 15.0 and 16.0 and say "a larger
number implies that the sofware is (slightly) more stable". In this
context, Matts proposal to use the number of commits makes most sense,
but I think sticking with the existing process and just increment the
number every release is easier to handle.
I think dropping the 0 prefix is the easiest way to get rid of the
regular discussion to bump to 1.0.0.
|
|
NACK on using number of commits. For instance, "Bitcoin v12821" (commits at time of writing) should not be used because it isn't a tagged release and numbering by commits implies that it is. |
|
Sorry, that wasn't a serious proposal, indeed the usability issues of that are too high. It was only a demonstration of how little effort I think we should put into this issue.
…On January 31, 2017 10:05:50 PM EST, Jeremy Rubin ***@***.***> wrote:
NACK on using number of commits.
For instance, "Bitcoin v12821" (commits at time of writing) should not
be used because it isn't a tagged release and numbering by commits
implies that it is.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#9653 (comment)
|
|
I disagree. Version numbers are pretty important for users! I think that overall an acceptable "compromise" would be to jump versions by a few and release 0.14 as Bitcoin 17 to mean Bitcoin 2017. If there are multiple releases intended in a given year, then it should be marked as YY.MM, eg 17.02 for a release in February 2017. This is how Ubuntu does it IIRC, and it works pretty well I think (we'd never really do 2 versions in a month...). A downside is that if, for some reason, there is no release for a year you skip a version number! Any releases can be handled as a counter at the end, e.g., 17.02.011, 17.02.012. |
|
I don't like the idea of commits (they don't mean anything) nor the idea of jumping from v0.1x to v1(x+1) for the sake of marketing or image. I am in favor of option 2) (agree on a set of milestones leading to v1.0.0) but if only if SemVer is adopted at the same time (otherwise there's no point in trying to attach meaning to any version string, now or in the future). v1.0.0 could be introduced instead of v0.2.0 (or any other soon-ish release) as part of official transition to SemVer versioning, for example.
I agree, but let's also consider the meaning of the rest ( |
Yes, indeed. We have a strictly time-based release process: a major release every 6 months, minor releases as necessary. Every major release, the second number is increased. This is completely predictable and requires zero discussion, which makes it very efficient. As there are always two major releases per year, this also means that @JeremyRubin's idea to go to purely year-month based version numbers isn't that crazy. For major releases, minor releases would still get a |
|
I agree with number 2 About what @MarcoFalke said...
I don't know how does other people feel about that, but for me 2.x.x always implied that it has been overhauled and/or most, or the most important parts, of the code have been rebased. |
|
As I understand semver does not care about the quality of the code base or the maturity of the software at all. If we decide to adopt semver, our version number pretty much only indicates what happens with the public api. http://semver.org/#spec-item-5
|
|
Ideal is that patch bump ( In that context, maturity and quality increase at |
|
Did we come to conclusion here? Or are we punting? |
|
Now that btc1 have hijacked the version of Bitcoin, I think the best way forward is to adopt the versioning system proposed by Jeremy Rubin using year and month (Ubuntu style), as we now run a big risk of new users seeing "1.14 and 0.15" and thinking the former is newer. |
|
@kallewoof I agree this is good to do. I don't think it will be super-effective against btc1 confusion, because they may also elect to use this release system (although perhaps not). If there is no strong opposition, perhaps you/we should draft a more formal documentation change to make this clear. I would propose that to do this we do an immediate release which reversions the latest release (0.15.0.1) as 17.10.x. This would change the Schedule for 0.16 #11449 to be releasing version 18.5.1. If we also want to do something like Ubuntu with having adj+animal releases, maybe something like 'Bumpy Barnacle' or 'Boisterous Beagle'. |
If/when releases start getting nicknames, I'd really prefer iterating over a different subject - not animal names - and big bonus if that subject has meaning to crypto. I suggest adj+math/cs/crypto term. Adjective also being a math/cs/crypto term is a bonus. Some examples:
|
|
FWIW I don't like the idea of a name at all, version numbers are clean, simple and easy to come up with ;) |
|
@TomasJuocepis disagree. This will be confusing for users expecting there to be a feature relating to that. names should be somewhat irrelevant. @meshcollider There is a simple reason for it, you need a stable name for the version pre-release. |
|
I also prefer to not use names. We're generally only working on one release at a time. The stable name for the version pre-release is 'the next version'. |
|
'The next version' doesn't help for searching through email archives |
|
@JeremyRubin, it'd be a stretch to interpret most of the listed names as actual features. I think you're not giving enough credit to the users' competence. Having said that, I see your point and mostly agree. After thinking more about it, I think the bigger issue would be not the user confusion, but occasional accidental confusion during discussions when mentioning the version names in the context of similar concepts and terminology being discussed. I guess I'd be happy with Alice Core, Bob Core, Carol Core, ... the Core family. |
|
@vinniefalco Bitcoin and Bitcoin Core aren't finished or ready for mainstream use. 0.x fits perfectly to convey a correct understanding on this. |
I agree that 0.x implies "not finished or ready for mainstream use."
The optics on this are even worse than using a beta version number to label a finished product. Is it possible that perhaps the criteria for "finished" are either impossible to achieve or poorly defined? |
|
@vinniefalco No, the criteria are not impossible nor poorly defined. |
|
I'm in favor of dropping the zero. I disagree that there will be a point where a discrete transition from "immature" to "mature" will happen. No software is ever finished, but the procedures this project is following (testing, compatibility across versions, release schedule, ...) certainly already follow an expectation of stable interfaces and operation. I believe that is a better criterion anyway than a vague "ready for mainstream use" (certainly our software's versioning shouldn't depend on its audience or on the currency's adoption). As a result, I think the 0 is just redundant. Of the various ways to proceed I think shifting up the digits has the least risk of incorrectly being interpreted as a major event instead of just recognizing that the zero serves no purpose. |
|
@luke-jr Honest question - what are the criteria? |
|
@sipa No software is ever finished, but being reasonably ready for mainstream use before leaving 0.x seems like an obvious criteria to wait for. I'm sure we could come up with a more specific definition if that's important to some people, but it's pretty obvious we're not there yet either way. |
|
@luke-jr You say that "the criteria are not impossible nor poorly defined" - where are they defined at all? My vote would be for using SemVer 2.0.0 - and move to that by dropping the current "0." prefix. Could we then increment the MAJOR version for API breaking changes, (or even, a hypothetical future hard fork version) the MINOR version for a version which contains a soft fork or backwards compatible API change and the PATCH for bug fixes? |
|
We had 0.15.0.1 for instance and IMO that sounds confusing to users.
@luke-jr what would be considered ready for mainstream? Anyway, I like this policy https://www.postgresql.org/support/versioning/. |
|
@promag A few obvious things that come to mind (not intended to be a comprehensive list):
Part of the problem here is that Core includes so many different things at different stages of development. The consensus code should probably be something like version 2.4.1, but the wallet stuff is far from ready for a 1.0. |
|
I'm in favour of dropping the 0 and using a semver 2.0 style. I dislike the Debian style with naming each release (i have to look up each time someone references a release name), and I also dislike timeframe specific versions like Ubuntu, because it doesn't include any information how much has changed and if there are any breaking changes. |
|
@luke-jr I cloned the repo and tried to build it on Windows. I also ran the installer version and synced. I agree with you somewhat now, it isn't in the best shape. |
|
I'm pretty strongly in favor of the HARDFORK.MAJOR.MINOR versioning scheme mentioned here: #12026 (comment) Did I miss some discussion as to why people are opposed to this? |
|
I don't understand why we should tie hardfork number and bitcoin core version. |
|
I think the solution would require a couple things:
1. A way to indicate major changes to the consensus rules, requiring a hard
fork.
2. A way to indicate significant software inprovements/features.
3. A way to indicate minor patches to aforementioned features.
4. Seamless transition from the current state so it doesn't seem a major
event took place, and cause a stir.
With all the above, I think the best solution would be:
<HARD_FORK>.<MAJOR_VERSION>.<MINOR_VERSION>
This would both satisfy the above requirements, and not require a change to
the current state until the next hard fork is needed.
…On Dec 29, 2017 11:56 AM, "João Barbosa" ***@***.***> wrote:
I don't understand why we should tie hardfork number and bitcoin core
version.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#9653 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AP829lyP11y1klaustC9LQDjIM-Gwiayks5tFRmmgaJpZM4LxY7j>
.
|
|
@promag How do you expect people to easily know whether they are running compatible software after the hard fork other than by the version number? |
|
What I mean is that the first component could be increased not only because of a hard fork. As others suggested, I like semver2 |
|
@promag From 2014 to now the highest a minor version number has been was 4 (0.10.4) or 3 otherwise. In 2013 there was 0.8.6. The minor version number is already used underwhelmingly, adding a patch component seems like a waste. |
|
To reiterate from the other thread, we're currently doing softforks as minor versions and I think we should do the same for hardforks. Alternatively, we could increment the first number with either hardforks or softforks. Both are consensus changes and I don't see why hardforks should have special treatment in the versioning. So, either way, nack on the |
|
@coyotte508 the |
|
To me it seems tangent to be discussing hardforks, this is just the version number for Bitcoin Core not the Bitcoin protocol |
|
If a hardfork was deployed in a planned manner with a year or more activation delay, I don't think encoding it in a version scheme would make much sense: there'd be multiple releases with hardfork support before the pre-hardfork software is unable to follow the chain. I don't think there's much value to adding a hard fork counter: at the time the hard fork's about to activate, you just have to say "the current version is 25.2.3, make sure you're upgraded to at least version 19.0.0 to cope with the hard fork coming next week". In that scenario, using hardfork-major versioning seems mislading: 0.18 and 1.19 aren't incompatible and won't be for a few years. |
I agree that a version that implements a hard forking change should prominently convey this information. However, I highly disagree that a hard fork should be accompanied by a version bump. That falsely also conveys (to some) that a hard fork is always better that a previous version that does not implement the hard fork. (The version number is larger, so it must be better, ...) Also, bumping the version number in case of a hard fork implementation does not work very well with backports. Assume a hard fork in version 0.x is backported to version 0.(x-1), you can't really bump both to the same 1.0.0 version... I see two ways to convey that a software version implements a hard fork:
|
|
The feature request didn't seem to attract much attention in the past. Also, the issue seems not important enough right now to keep it sitting around idle in the list of open issues. Closing due to lack of interest. Pull requests with improvements are always welcome. |
A hard fork should be better than a previous version that does not implement the hard fork. Otherwise, why bother to do the release at all? Also, there are plenty of examples of software where larger version numbers are not better than older versions (at least in the opinion of some users). It's why sites like Old Version exist. So I don't think this particular aspect is a downside. |
and others
In #8455 (comment) the versioning of Bitcoin Core was mentioned, but deemed off-topic, so I am creating this issue to address the fact that Bitcoin Core uses a non-traditional scheme for version releases.
To me, the first (traditionally "major") version number is
0for as long as a product is considered non-production-ready, and>0for production-ready, and bears significant meaning in this sense.Possible mind-sets:
0.is dropped, meaning that the next version is14.0not0.14.0.1.0release.The text was updated successfully, but these errors were encountered: