-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
0.0.9 UI #243
0.0.9 UI #243
Conversation
…e into 0.0.9-Z-UIAlpha Conflicts: src/rpcmisc.cpp
…nto 0.0.9-Z-UIAlpha Conflicts: src/rpcmisc.cpp
…nto 0.0.9-Z-UIAlpha
…nto 0.0.9-Z-UIAlpha Conflicts: src/mastercore.cpp
…nto 0.0.9-Z-UIAlpha
…nto 0.0.9-Z-UIAlpha
…nto 0.0.9-Z-UIAlpha
This PR should be based off 0.0.9 branch, and it should be up to date (a git pull from parent gives me an 'already up to date'). The only other branch I could base it on is 0.0.10 but we're not ready for that yet. |
Can result in a failed LOCK otherwise: Assertion failed: lock cs_main not held in main.cpp:596; locks held: wallet->cs_wallet mastercore.cpp:2718 See: mastercoin-MSC#243 (comment)
It's no longer used and can be removed.
QT: refine "Overview" and "Send" related issues
Thanks for the merge @zathras-crypto. For the reader: zathras and I continued the discussion via email. I have tested and reviewed this branch in detail, both on Ubuntu and Windows and it's stable and ready to merge, in my opinion. @m21 |
Gotta take this in sooner rather than later for sure. |
Huh? Plan was always to release UI after STO as 0.0.9.1 - merging to Can you please rethink mate? Thanks
|
QT: avoid version incompabilities
I think don't understand that versioning scheme... or maybe I do: how about you increase the second last digit for consensus breaking updates and the last one for anything else? Say for example:
Anyway, I do not approve a plan where the UI update is held back until DEx phase 2, especially given the earlier delays, which were seemingly justified with actually unrelated issues (missing LOCK, conflicting unconfirmed transactions after start, ...), as it turned out, as well as the announcement on Jan 31:
|
FYI versioning scheme: 0.0.x.y Each X (branch) release requires everyone to upgrade and must be a well managed release. TL:DR; we can do as many 0.0.9.x as we like, as long as none of them impact consensus (because then older versions of 0.0.9 are not required to upgrade). That was my intention when I put in that mastercore_version stuff, apologies if I didn't communicate that well. The UI is non-consensus affecting and thus I thought it had all been agreed to do UI as 0.0.9.1? Thanks |
Nice, this sounds as it should be, in my opinion. Maybe it would make sense to have a third category for non-backwards compatible API/RPC changes, which are not consensus breaking at the same time, say |
Thanks guys, after a chat with Zathras it makes sense to pull non-consensus changing UI-code into 9 and into 10 at the same time. |
Pew. Happy "to get rid" of this mega thread finally. :) Thanks @m21. |
Yep :) Think next stage is to do some builds (preferably gitian) and pop the bins out internally, if no objections/bugs raised then tag 0.0.9.1? EDIT: when I say internally, I mean so we can test (eg I'll pop windows daemon up for Sean to consensus test against and so on) |
@zathras-crypto: I tested building for Windows via Gitian, involving some workarounds, see: #284. I'm going offline in a few minutes, but would be interested in working this one out. :) |
Contains various bits that got layered - sorry about that all.
I have one issue that I still haven't been able to narrow down, and that's randomly the GUI will not display at startup after init maybe one out of five times - can anyone replicate?