MS Windows build of Steem v0.12.0 is released.

https://github.com/btscube/steem/releases/tag/v0.12.0

You will need Visual C++ Redistributable Packages for Visual Studio 2013 . Download it here - https://www.microsoft.com/en-us/download/details.aspx?id=40784

From Steem github, changes made in this release are :

Issue #176

Each root level comment has a reward weight which impacts the end payout of the post. We are targeting 4 posts in 24 hours. Your first 4 posts in 24 hours will not be penalized. After that, they weight is decreased from 100% based on your average posting frequency. Having a frequency just barely higher than 1 every 6 hours will have very little impact, while spamming will be penalized heavily. This change is aimed to increase the quality of content at the cost of quantity.

Issue #177

Each discussion goes through a two stage payout. The first one is nearly identical to what currently happens on a new discussion except that we are weighting payout times by 12 hours instead of 24. This should cycle through currently trending content quicker. There is a second voting period set to 30 days after the first payout. This should help posts that don't have immediate viral success accumulate votes and have more consistent payouts in the long run. After the second payout a discussion becomes "frozen". The discussion is no longer editable and new replies are disabled. Users can still vote on comments in these discussions as a "nod" to the author without costing their posting power or awarding reward shares.

Issue #178

There has been a lot of controversy surrounding liquidity rewards. We are refraining from making a judgment at this point but want to spend more time reviewing their impact. We do believe that in their current form the liquidity rewards are simply too much for the value thy provide. As such, we are temporarily disabling liquidity rewards until we can design a better solution. In the meantime, a transaction fee free market should be incentive enough for users to continue to use the Steem internal market.

Issue #179

The average block size calculation is too high. We are reducing the minimum block size limit from 128k to 64k and changing the average block size threshold from max_block_size / 2 to max_block_size / 4. The net result is that the average block size threshold can be 4 times smaller. If witnesses chose to vote this way, it will make triggering transaction bandwidth limits easier, which is currently not applying except in the most extreme circumstances.

Issue #184

Fixed a bug in the cli wallet that incorrectly allowed the wallet to attempt to broadcast an update account operation from a locked wallet. The broadcast would fail but created a poor user experience.

Issue #186

Added recovery operations to account history so they can be tracked more easily.