Skip to content
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

Release/v1.2.4 #3756

Merged
merged 18 commits into from
Dec 6, 2019
Merged

Release/v1.2.4 #3756

merged 18 commits into from
Dec 6, 2019

Conversation

ripcurlx
Copy link
Contributor

@ripcurlx ripcurlx commented Dec 6, 2019

No description provided.

ripcurlx and others added 18 commits November 27, 2019 08:51
With v1.2 we use 2of2 multisig for deposit tx. This commit changes the
manual payout window to reflect that.

- Remove unused code from legacy arbitration
- Fix comments
With link to v1.2 dispute resolution documentation.
Fixes #3721 and
#3722

There are still more issues as such a payout tx will cause that the
trade ends up in failed trades. This commit only fixes the invalid
tx issue.
If we do not get any BTC from a mediated payout tx we do not know about
the confirmation state so it would stay always in the unconfirmed state.
To avoid that confusion we prefer to hide the icon. This is a known
issue from BitcoinJ but we have not found a solution for that yet.
Fixes #3721
(part of the problem was that the trade ended up in failed trade)

Refactor method and add comments.
We did not handle the case of a mediated payout. isPayoutPublished() is
only reflecting non-disputed trade payouts.
We had a small memory leak in the code base. Namely, there have been some
threadpools in use but not shutdown when they have been no longer needed.
Result was that the threads and the parent threads have been kept alive
which lead to hundreds of stale threads over the course of several days.
* Update bitcoinj checkpoint file

* Update translations

* Update data stores
….2.4

# Conflicts:
#	core/src/main/resources/i18n/displayStrings_zh-hant.properties
@ripcurlx ripcurlx requested a review from sqrrm as a code owner December 6, 2019 10:31
Copy link
Member

@freimair freimair left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

utAck

@ripcurlx ripcurlx merged commit 0cfa7f6 into master Dec 6, 2019
@julianknutsen
Copy link
Contributor

@ripcurlx

Is this the standard way that every release branch is done?

  1. Commit changes to master
  2. Cherry pick changes from master->branch
  3. Add release-only changes such as translations, version numbers, data stores on branch
  4. Merge release-only changes to master after release

What happens if there are changes that are only on the branch because master has changed by the time the merge happens? Who handles the merge?

What is the downside of adding all the changes that were originally just on the branch to go to master first and cherry-picked to the branch?

I know there are a ton of branching models so just want to understand this one :)

@ripcurlx ripcurlx deleted the release/v1.2.4 branch January 3, 2020 11:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants