Wiremock: Feature Request: Change log or release notes

[ntam]

I have been using the version 2.6 but now the last version is 2.19 but I don't know if I can upgrade without issues or which are the changes, bug fixes, new/removed features.

Could you please let me know if the upgrade is possible without problems or which changes I would need to apply on actual mappings?

could you consider implement a change log or release notes, please ?

Thank you for your great work on this tool.

[tomakehurst]

I publish a release note on the mailing list every time I push a new version, so I'd suggest taking a look at these.

More generally, I think you'll have no problem upgrading as we work pretty hard not to introduce breaking changes within major versions.

[ntam]

Thanks for your quick answer, anyway having a release notes in the project is very useful for everyone involved or using wiremock, suscribed or not in the mailing list.
e.g:
https://github.com/RMerl/asuswrt-merlin.ng/blob/master/Changelog-NG.txt

p.s.: it's a bit difficult find the release notes in the mailing list due to the lot of messages.

[tomakehurst]

Yeah, I agree it's not the most user-friendly way to do it, and it'd be nice to have a proper releases page on the website.

I'll mark this as a feature request.

[tomasbjerre]

I generated a changelog here: https://github.com/tomasbjerre/wiremock/blob/feature/adding-changelog/CHANGELOG.md

Using:

npx git-changelog-command-line -std -tec "
# Changelog

Changelog for {{ownerName}} {{repoName}}.

{{#tags}}
## {{name}}
 {{#issues}}
  {{#hasIssue}}
   {{#hasLink}}
### {{name}} [{{issue}}]({{link}}) {{title}} {{#hasIssueType}} *{{issueType}}* {{/hasIssueType}} {{#hasLabels}} {{#labels}} *{{.}}* {{/labels}} {{/hasLabels}}
   {{/hasLink}}
   {{^hasLink}}
### {{name}} {{issue}} {{title}} {{#hasIssueType}} *{{issueType}}* {{/hasIssueType}} {{#hasLabels}} {{#labels}} *{{.}}* {{/labels}} {{/hasLabels}}
   {{/hasLink}}
  {{/hasIssue}}
  {{^hasIssue}}
### {{name}}
  {{/hasIssue}}

  {{#commits}}
**{{{messageTitle}}}**

{{#messageBodyItems}}
 * {{.}} 
{{/messageBodyItems}}

[{{hash}}](https://github.com/{{ownerName}}/{{repoName}}/commit/{{hash}}) {{authorName}} *{{commitTime}}*

  {{/commits}}

 {{/issues}}
{{/tags}}
"

There is also a gradle plugin that may fit this project better:
https://github.com/tomasbjerre/git-changelog-gradle-plugin

[ntam]

Good work guys and thank you for your contributions, keep going making the world a better place.

[norrisjeremy]

Please consider finding a way to generate some sort of change log or release notes.
The latest release breaks spectacularly for a project of ours and not having any sort of change log or release notes makes it extremely difficult to understand what is breaking.

[tomakehurst]

1) Can you share what's broken? We're not in the habit of putting breaking changes into minor version releases, so it'd be useful what the actual problem is.

2) I always publish a summary of changes on the mailing list when pushing a release: https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!topic/wiremock-user/dFqib2uesiY

3) If the change summary isn't enough, then e.g. git log 2.26.3..2.27.0 is your friend.

[norrisjeremy]

We use the wiremock-extension project (https://github.com/JensPiegsa/wiremock-extension) to allow JUnit5 compatible injections into our unit tests and it blows up like this:

com.github.tomakehurst.wiremock.common.FatalStartupException: java.lang.RuntimeException: java.security.UnrecoverableKeyException: Cannot recover key
    at com.github.tomakehurst.wiremock.WireMockServer.start(WireMockServer.java:149)
    at com.github.jenspiegsa.wiremockextension.WireMockExtension.startServer(WireMockExtension.java:166)
    at java.util.ArrayList.forEach(ArrayList.java:1257)
    at com.github.jenspiegsa.wiremockextension.WireMockExtension.beforeEach(WireMockExtension.java:107)
...

We understand that since it's a third-party extension, we're on our own to make it work, but not having an annotated change log or release notes (that link to back to specific Github Issues or PRs) like many other projects, makes investigating this kind of breakage far more difficult.

[tomakehurst]

Are you using your own keystore with a non-default password?

[norrisjeremy]

Yes:

  @ConfigureWireMock
  public Options wireMockConfig =
      wireMockConfig()
          .port(8098)
          .httpsPort(8099)
          .keystorePath(keystorePath)
          .keystorePassword(keystorePassword);

[tomakehurst]

OK, congratulations - you've tripped over the one breaking change we did have to make :-)

Previous to 2.27.0 there was no way to set a keystore password, and keystorePassword() was actually setting the key manager password.

This has been fixed now, with the effect that keystorePassword() is passed to a different place.

If you try changing keystorePassword to keyManagerPassword that should do the trick.

[norrisjeremy]

Thank you so much for you quick response, adding keyManagerPassword(...) corrects the unit test failures we were seeing:

  @ConfigureWireMock
  public Options wireMockConfig =
      wireMockConfig()
          .port(8098)
          .httpsPort(8099)
          .keystorePath(keystorePath)
          .keystorePassword(keystorePassword)
          .keyManagerPassword(keystorePassword);

[tomakehurst]

No problem, glad it fixed it.

In future, please maybe consider asking for help and posting full problem details rather than posting an oblique complaint on a random issue?

Us OSS maintainers devote a lot of unpaid evening and weekend hours getting releases like this out. This one has been particularly hard work for two of us who are both also home schooling our kids at the moment. Please remember that before hitting send, and also that you always have the option of rolling up your sleeves and contributing a PR if you feel strongly that something is needed.