Implements #1948
CLIENT_VERSION_IS_RELEASE to clientversion.hfalse):bitcoind, show the warning in the "errors" field in getinfo response.This does not disable any functionality. Acting on the warning (or not) is the user or developer their own responsibility.
Please update doc/release-process.txt if this requires a change to the release process.
Could this be automagically defined if git HEAD has a tag, so we don't have to remember to define/undefine it?
I thought about triggering it on minor=99, I think that would label "dangerous" versions automatically.
As for git magic, I don't know.
Sometimes the version number in merge windows is ..99.0, and sometimes it's .._.99 - depending on what release we're aiming at. Testing for this would be a way, but I'm not sure.
The question is where do you put the border between showing the warning and not. Final releases obviously not, within-merge-window code obviously does. But what about release candidate, for example? If almost all code has the warning, people may ignore it.
Implements #1948
- Add macro `CLIENT_VERSION_IS_RELEASE` to clientversion.h
- When running a prerelease (the above macro is `false`):
- In UI, show an orange warning bar at the top. This will be used for other
warnings (and alerts) as well, instead of the status bar.
- For `bitcoind`, show the warning in the "errors" field in `getinfo`
response.I've updated the release process to set CLIENT_VERSION_IS_RELEASE to true before a release.
We do know for sure that the current state is dangerous, so IMO we should merge this as soon as possible, and get the edge-cases clear later.
Pragmatic solution: we could just set it to false next time we think the state of the tree is dangerous enough to warrant a warning.
"Pragmatic solution: we could just set it to false next time we think the state of the tree is dangerous enough to warrant a warning." @laanwj I really like that one! Btw. why are there so many changes in the UI file? Is it because of a different layout chosen?
Edit: I seem to miss the bitcoind changes?
92 | @@ -92,6 +93,8 @@ class TxViewDelegate : public QAbstractItemDelegate 93 | OverviewPage::OverviewPage(QWidget *parent) : 94 | QWidget(parent), 95 | ui(new Ui::OverviewPage), 96 | + clientModel(0), 97 | + walletModel(0),
Good catch, as such a thing did cause a crash a few versions ago.
@diapolo getinfo returns GetWarnings("statusbar"), so no special changes are needed for rpc
There are really very few changes to the layout, try git diff -b (ignore whitespace changes) or use a character-wise diff tool instead of github's line-based one. The only thing that happened is adding an outer element, so the whole thing got indented.
I didn't look into the getinfo code, thanks for explaining :).
ACK to get this in ASAP.
20 | + <widget class="QLabel" name="labelAlerts"> 21 | + <property name="visible"> 22 | + <bool>false</bool> 23 | + </property> 24 | + <property name="styleSheet"> 25 | + <string notr="true">background-color: qlineargradient(x1: 0, y1: 0, x2: 1, y2: 0, stop:0 #F0D0A0, stop:1 #F8D488); color:#000000
I did a compare and you are right, mostyl indention changes.
This line seems a little garbeled and misses an ; at the end, should be more like:
<string notr="true">background-color: qlineargradient(x1: 0, y1: 0, x2: 1, y2: 0, stop:0 #F0D0A0, stop:1 #F8D488); color: [#000000](/bitcoin-bitcoin/000000/);</string>
Looks nice! ACK