Prepare a new compatibility release v0.6.6. #203
Conversation
creachadair
requested review from
alexanderbez,
cmwaters,
tac0turtle,
tychoish and
williambanfield
as code owners
Codecov Report
@@ Coverage Diff @@
## master #203 +/- ##
===========================================
+ Coverage 11.75% 68.82% +57.07%
===========================================
Files 31 27 -4
Lines 1914 2111 +197
===========================================
+ Hits 225 1453 +1228
+ Misses 1656 583 -1073
- Partials 33 75 +42
|
There was a problem hiding this comment.
I haven't scrutinised all these changes as I assume they all come from the reversion so it LGTM 👍 . I would advocate, as I don't think it will be too much work, to eventually dump all the breaking API changes into a v2 directory and cut it as a v2 go module. I'm fine with having this as a 1.0 and 2.0 as I don't foresee too much work happening with this repo other than the odd version bump and thus these API's should be pretty stable.
There was a problem hiding this comment.
please work off of https://github.com/tendermint/tm-db/tree/release/0.6.x for a 0.6.x release. Not sure theres a need to make this more complicated
creachadair
force-pushed
the
mjf/release-next
branch
from
ba884f0
to
ccad95f
Compare
I have done the rebase, but we can't eliminate the revert, since the API changes are already on the branch history. Well, we could rebase them away, but then the history would diverge not only from the 0.6.5 release but also master. If you prefer that we can do it, though. |
creachadair
force-pushed
the
mjf/release-next
branch
from
4176f28
to
ccad95f
Compare
Actually, it's worse than I realized: The 0.6.x release branch was already allowed to diverge from the tagged history of master at v0.6.4 (i.e., the tag precedes the branch and master does not follow it). It looks like maybe this was not set up as a proper backport branch, so the histories are already divergent even before we started. |
creachadair
force-pushed
the
mjf/release-next
branch
from
0f44e4d
to
ba884f0
Compare
…Store (#187) * Add an option to create MemDB iterators with no Mutex for the CacheKVStore * Update changelog
|
do you think we could get #205 before doing 0.6.6? |
I merged it into this PR from the side-spur of the release branch. I think it probably does make sense to include it in v0.6.6, and I updated the changelog on that basis. |
This PR prepares the changelog and commit history for a v0.6.6 release.
The API changes in tag v0.6.5 have been preserved in the new
package-reorgbranch, so that any existing dependents will continue to work. This change reverts the breaking API and package structure changes on master, and prepares to tag a new release compatible with the previous v0.6.4 so that normal upgrades withgo getwill function correctly.Other changes since v0.6.4, including config file changes and CI updates, are preserved.
Note that if we do want to tag a new release with the breaking API changes, it will need to use a different import path to avoid colliding with the semver namespace of the main branch. This PR does not address that, but keeps the work around so we can handle that separately. A submodule would be one option, if we don't want to split the repository.