Changelog and release notes for 0.0.10

[dexX7]

It would be great, if the changes since the last release would be documented.

I think there is no need to go into very much detail for the obvious parts, but there are a few points, which are good to know:

• new transaction types for token exchange
• rebranding (file names!)
• OP_RETURN data embedding
• new API calls
• new configuration options
• debug log customization

[zathras-crypto]

Changelogs have been requested by integrators before, and I thoroughly agree we need one - we're probably talking on the order of 4 digit commit counts so obviously not feasible to stipulate every commit, but agree stepping through and highlighting everything substantial should be done.

[dexX7]

edit: I try to keep this post up-to-date.

After reading through the PR titles, this is a potentially incomplete list based:

Since Master Core 0.0.9.1:

- Upgrade code base to Bitcoin Core 0.10.2
- Select only coins, which can be spent 
- Fix shutdown issue after running Boost tests
- Finalize MetaDEx logic
- MetaDEx user interface
- Support creation of any (enabled) Omni transaction via RPC
- Support Class C/OP_RETURN encoded transactions
- Report initial parsing progress during startup
- Handle shutdown requests during initial parsing
- Integrate Travis CI and OmniJ into workflow
- Allow debug levels to be specified without needing to recompile
- Set `txindex=1` flag during startup, if confirmed by user
- Various code cleanups and improved code documentation
- Resolve and refine several `LOCKs`
- Support concurrent RPC queries
- Show script verification errors in `signrawtransaction` result
- Enable pay-to-script-hash support in send dialog
- Return all available information via `validateaddress`
- Indicate "pending" status of outgoing transactions
- Log every invalid processing of Omni transactions
- Rebrand project to Omni Core
- Rename files to `omnicore-qt`, `omnicored`, `omnicore-cli`, ...
- Fully support cross-plattform, and deterministic, building
- Unify and improve RPC help descriptions
- Fix shutdown issue after declining to reindex blockchain
- Add images to installer icon for deterministic building
- Reduce math and big numbers in crowdsale participation

Since 374779dbb6, the first developer preview:

- #128 Run OmniJ tests with all build targets except OS X
- #131 When closing a crowdsale, write info to debug log, not file
- #133 Report progress based on transactions, report estimated time remaining
- #132 Reduce amount of verbose logging by default
- #140 Use higher resolution program icons
- #145 Implement tally hashing for consensus testing and checkpoints
- #146 Fix trading restrictions for testnet
- #136 Skip loading unneeded blocks during initial parsing

Since b50c70e08a, the second developer preview:

- #150 #152 Add MetaDEx guide documentation
- #149 Update Omni Core API documentation
- #156 Move simple send logic and friends to the other logic methods
- #159 Implement and switch to Feature-Activation-By-Message
- #161 Don't spam log about non-sequential seqence numbers
- #163 Prepare deactivation of "grant tokens" side effects
- #164 Add hidden RPC command to activate features
- #158 Trigger UI updates after DEx payments and Exodus purchases
- #173 Fix/add missing fields for transaction retrieval via RPC
- #177 Sanitize RPC responses and replace non-UTF-8 compliant characters
- #178 Fix Omni transaction count value passed into block end handler
- #179 Add consensus checkpoint for block 370000
- #180 Update seed blocks to 370000
- #181 Update base to Bitcoin Core 0.10~ tip
- #174 Add RPC support for unconfrimed Omni transactions
- #184 Stop recording structurally-invalid transactions in txlistdb
- #167 Mostly cosmetic overhaul of traditional DEx logic
- #187 Automate state refresh on client version change when needed
- #195 Refine amount recalculations of traditional DEx via RPC
- #160 Improve wallet handling and support --disable-wallet builds
- #197 Reject DEx "over-offers" and use plain integer math
- #203 Minor cleanup of MetaDEx status and RPC output
- #207 No longer allow wildcard when cancelling all MetaDEx orders
- #209 Remove unused addresses in MetaDEx cancel dialog after update
- #210 Don't restrict number of trades and transactions in UI history
- #213 Refine RPC input parsing related to addresses
- #217 Rebrand "Mastercoin" to "Omni"
- #218 Fix/remove empty build target of Travis CI
- #220 Fix Bitcoin balance disappears from the UI on reorg
- #221 Don't call StartShutdown() after updating config
- #223 Fix calculation of crowdsale participation on Windows
- #224 Update links to moved API documentation
- #225 Rebrand token and fix links to RPC API sections
- #227 Do not save state when a block fails checkpoint validation
- #229 Minor update to MetaDEx guide

Since d62b0a9649, the third developer preview:

- #238 Fix crowdsale purchase detection in test ecosystem
- #231 Change icon to make Win64 installer deterministic
- #240 Various small improvements to ensure correct state
- #232 Add new RPC to list pending Omni transactions
- #243 Fix STO DB corruption on reorg
- #239 Fix "raised amount" in RPC result of crowdsales
- #234 Update documentation of configuration options
- #233 Use tables and add results to JSON-RPC API documentation
- #250 Fix missing crowdsale purchase entries in verbose "omni_getcrowdsale"
- #253 Update handling of crowdsales and missing bonus amounts
- #142 Add RPC to decode raw Omni transactions
- #176 Implement updated alerting & feature activations
- #252 Restrict ecosystem crossovers for crowdsales
- #258 Explicitly set transaction and relay fee for RPC tests
- #260 Add ARM and a no-wallet build as build target for Travis CI
- #262 Filter empty balances in omni_getall* RPC calls
- #263 Update base to Bitcoin Core 0.10.3

Notable changes:

- file names changed from "mastercore*" to "omnicore*"
- default log file changed from "mastercore.log" to "omnicore.log"
- RPC results for traditional DEx offers no longer use
  "subaction", but "action": "new", "update", "cancel"
- minrelaytxfee raised, and thus dust threshold

I'm not sure, if this is very helpful, but probably a start.

When going through the commit log, oh well.. there is so much information.

For the future: please let's create PRs with only one, single, purpose, and clear titles, which can be copied 1 to 1 into the next chagelog, hehe.

Alternatively, we could start with the notes or changelog right from the beginning, and update it frequently. This should probably not be done in this repo, but somewhere at least.

[dexX7]

I'm going to keep the list updated, and add new entries, once the PRs are merged.

But let's discuss the general plan for the future: while a list with PR titles isn't bad, it's not necessarily very useful, given that titles are usually pretty short and consist mostly of keywords. I don't really see a great alternative, except using commit titles, and no PR titles.

Alternatively we may create a new document, which should be updated, if a new PR is proposed/merged, sort of like maintaining the documentation in parallel?

[zathras-crypto]

I'm not sure, if this is very helpful, but probably a start.

Hugely helpful :)

For the future: please let's create PRs with only one, single, purpose, and clear titles, which can be copied 1 to 1 into the next chagelog, hehe.

Agreed - I'll try to "clean up" my work methods as I do have a habit of working on several different things at the same time and basing one new thing on top of another new thing - I'll try to be a bit better at branching :)

Alternatively we may create a new document, which should be updated, if a new PR is proposed/merged, sort of like maintaining the documentation in parallel?

Could we not simply require that every PR requires a "changelog description" text which is more descriptive that just a title and then use that to maintain a changelog? Just thinking out loud there :)

[dexX7]

Could we not simply require that every PR requires a "changelog description" text which is more descriptive that just a title and then use that to maintain a changelog? Just thinking out loud there :)

Haha, yes! Ideally the PR text includes a description, which could be read isolated (i.e. in a changelog/documentation), and should fully describe what the PR does (not necessarily how [code wise]). We should note that code discussion, and notes, and anything that is not descriptive-change-text should be posted in the second post. PR texts should be updated, if the PR was updated.

Sounds good? I have a bit a hard time to put this is more "user faced" words, but we should add a CONTRIBUTION.md file. See here the nice "hint", if one creates a new issue, and here the very awesome guidelines.

[dexX7]

I started to tag pull requests with labels (other than the status indicating labels we already use) to make it easier to categorize changes.

Please use labels, whenever you stumble upon something that is missing or needs to be updated. If no appropriate label is available, feel free to add new ones.. :)

[dexX7]

This also raises the question whether we should add labels for old pull requests.