Tag a release at latest master

[drltc]

I was running the latest release tag v0.4.24 and encountered a crash, which upon further investigation was #959. Can we tag master as v0.4.24.1 or v0.4.24a or something?

Also, do the binaries at http://bitshares.org/downloads/ have the fix?

[drltc]

According to the live web wallet release at http://bitshares.org/manifest.json we are at release 0.4.24-a. The manifest file doesn't say what resources it was built from, but I would assume it's the web wallet referenced in the latest master?

[vikramrajkumar]

No point doing this after waiting all these weeks. We should really put out an intermediate release soon with the latest stability fixes, since it will be an unknown amount of time before the next hardfork.

The manifest is a good point; @valzav @nathanhourt is there a way to tell what web_wallet commit you are running?

[drltc]

According to discussion on #1100, I believe the best practice is to not trust private keys that control real BTS to any branch except master. I haven't been actively trading, so I haven't accessed my BTS since sometime in October, meaning I needed to build the production client.

Here's the process I went through:

• Checkout latest tagged revision, v0.4.24, update all submodules, compile.
• Get crashing due to Withdrawal from wallet to "UNKNOWN" address #924.
• Okay, apparently latest version is untagged master branch which points to 1854346. Checkout that version, update submodules, compile.
• Now all my transaction history dates appear as January 1, 1970 because web_wallet@816cabf89951db5bdd044cbce93f2d00184f4311 isn't included in web_wallet submodule pointer.
• Change to web_wallet subdirectory, compile web_wallet@816cabf89951db5bdd044cbce93f2d00184f4311 .
• Dates are OK now, but I see "Test Network" in footer even though I am clearly live on mainnet. This is fixed in web_wallet@6cefda52fbf161e13b62ade1871506e67bbbba1b but that has not been backported to web_wallet master branch.

Bottom line is, we need to tag a new release ASAP which at minimum fixes these problems. Including abd15f0 would not be amiss either, and I'm sure there are plenty of other bug fixes that need to go out too.

I think releasing our existing fixes should be our goal for this week.

[vikramrajkumar]

According to discussion on #1100, I believe the best practice is to not trust private keys that control real BTS to any branch except master.

I would be slightly stricter in the wording and say best practice is that only official release tags or provided builds should be trusted, unless specifically suggested otherwise by a core dev.

As described by the current milestones https://github.com/BitShares/bitshares/milestones, putting out such a bugfix release is indeed my current focus. The current official release has been out for nearly a month without any large-scale emergencies, so I don't feel we are in a rush. Ideally we can put out an RC at the end of this week, but I would prefer to wait if necessary to include at least these significant updates:

• An updated candidate for the new transaction scanner (Tasks still remaining for new transaction scanner #845) that users would be able to help test before the next required upgrade
• Any fork handling fixes identified by @dnotestein or @emfrias as mentioned in Specifying an optional argument on the CLI requires all earlier arguments to be specified #1108 (comment)

[vikramrajkumar]

https://github.com/BitShares/bitshares/releases/tag/v0.4.25-RC1