Versioning is confusing when building master
so7ow opened this issue · comments
It seems to reflect the most recently released version of ord, which is very confusing to users, especially when master has a schema update and isn't compatible with the most recent release.
Example: at some point after 0.18.5 was released there was a schema update in the code. Now, if you build from master your binary will say it is version 0.18.5, but it won't read an index file created by the 0.18.5 release. ➡️ confusion
Any good way to change the version after a release, to reflect the unreleased nature of building from master?
The schema update is the most obvious manifestation of this issue, but even when there is no schema update it's still confusing for folks to build master and get an executable that lies about its version number.
I think that is just the nature of building from master. It should give you an error that the index.redb file needs to be upgraded. Something like this:
error: index at `/Users/raphael/Library/Application Support/ord/index.redb` appears to have been built with an older, incompatible version of ord, consider deleting and rebuilding the index: index schema 25, ord schema 26
I think that is just the nature of building from
master. It should give you an error that theindex.redbfile needs to be upgraded. Something like this:error: index at `/Users/raphael/Library/Application Support/ord/index.redb` appears to have been built with an older, incompatible version of ord, consider deleting and rebuilding the index: index schema 25, ord schema 26
Sure, I'm aware of that error, but that doesn't address the underlying issue I'm reporting: the fact that building from master produces an executable that reports a released version number, but isn't really that released version.
I'm not a dev, nor am I particularly proficient with GitHub, but as I understand it the bitcoin project has a method of dealing with this that seems fairly straightforward, if I'm understanding it correctly: they bump the version number to x.99 after publishing a release, so that if you subsequently build from master you get an executable of that x.99 version, rather than a mostly untested executable that reports the released version, but really isn't that version. It makes it crystal clear to anyone wondering, that the version running is not a released version.
Hopefully that wasn't too rambling. Cheers!
Thanks, that makes sense. I'll see what we can do about that
How about this?
That method seems to take care of the general case, but it still might lead to similar confusion after a schema update on master: "if 0.18.5 can read this index file, why can't 0.18.5-abcxyz?" The convention has always been that indexes are compatible until the next major release. Not sure if there's a great way around that.
I think if you are building from master it should be expected that you understand this error message:
error: index at `/Users/raphael/Library/Application Support/ord/index.redb` appears to have been built with an older, incompatible version of ord, consider deleting and rebuilding the index: index schema 25, ord schema 26
Combined with the indication that this version is built from a commit hash, this should probably be sufficient to alleviate most confusion. There's probably a more elegant way but I don't see it right now. Open for suggestions.
I think if you are building from
masterit should be expected that you understand this error message:error: index at `/Users/raphael/Library/Application Support/ord/index.redb` appears to have been built with an older, incompatible version of ord, consider deleting and rebuilding the index: index schema 25, ord schema 26
One might think that but spend some time in the Ordicord and you'll see that it's definitely not always the case. 🤣
Anyway, your proposal is an improvement. If anyone has any thoughts (or if I come up with anything myself) hopefully we can put it in this thread.
@raphjaph this is probably a naive question, but is there a reason why the change that bumped the schema wasn't segregated into a new 0.18.x version? Wouldn't that have allowed those using 0.18.5 to continue on using it without running into this error, and then anyone who wanted the new change could just build from 0.18.6 or master and be informed that a new index would be necessary? Granted, even this might be confusing for some users as it has been expected that one index for 0.18.x would be good across any 0.18.x version - but it could be explained as an exception to that rule.
Well, remember, if we're following convention the new schema would trigger a version bump to 0.19.0 in this case, not 0.18.6.
But yeah, maybe it's as simple as bumping the major version as soon as the schema change is made, rather than waiting for a release?
Well, remember, if we're following convention the new schema would trigger a version bump to 0.19.0 in this case, not 0.18.6.
But yeah, maybe it's as simple as bumping the major version as soon as the schema change is made, rather than waiting for a release?
right - that's why I mentioned that even going to 0.18.6 would cause confusion since it's still a departure from precedent, but maybe it's a consolation if for some reason they're not ready to go to 0.19.0 just yet? In any case, the question boils down to - why didn't the version get bumped for this schema change?
(And again, I'd like to say: the index incompatibility is only the most obvious issue. Under no circumstance (imo) should building from master create a binary that will report a version number that is no longer accurate.)
(And again, I'd like to say: the index incompatibility is only the most obvious issue. Under no circumstance (imo) should building from master create a binary that will report a version number that is no longer accurate.)
Sorry, but this is just false. It is common practice to not to increment the version number until a new release is made. The master branch is implicitly unstable. If you want a stable, released version, you should use a tag.
Opened #3916 to add -dev in Cargo.toml, to hopefully make this less confusing.
Sorry, but this is just false
Haha I don't know how an opinion can be false, but ok. Obviously master is unstable and I'll pick a tag to get a stable version. I just think it's a bad call to leave the version number such that an unstable build reports a stable version number. On the Ordicord, we've frequently seen the problems it causes.