Am 2018-05-05 um 13:23 schrieb Stephen Connolly:
On Sat 5 May 2018 at 09:13, Michael Osipov <micha...@apache.org> wrote:
Am 2018-05-05 um 09:15 schrieb Stephen Connolly:
On Thu 3 May 2018 at 22:10, Michael Osipov <micha...@apache.org> wrote:
Am 2018-05-02 um 10:41 schrieb Robert Scholte:
I don't see a new test[1][2], only rewrites to confirm there's no
regression.
I understand the issue, but we just need to be sure that nobody in the
future thinks that File.toURI() is short for File.toPath().toUri()
Robert
[1]
https://github.com/apache/maven/commit/43b34598629f086523a333dc18665389643832a5
[2]
https://github.com/apache/maven-integration-testing/commit/5e18bb18784585dfc822038f5229785d439c677b
Robert,
done some more digging and added unit and integration tests to it:
https://github.com/apache/maven/commit/9d29bb4d91e9545a9b5bc2957646ad42d5add210
https://github.com/apache/maven-integration-testing/commit/1f4912cda5f49b6ba36a2693bb5c1701ea4d9b86
Though, the IT reasonably runs on Unix if UTF-8 is set as file.encoding.
I have also updated the ticket with more description.
I think that this issue should be pushed to 3.6.0.
Unclear why you think it should be dropped from 3.5.4. We’re not changing
an API, only fixing a bug...
This fix introduces a change in behavior. It might be unexpected in a
fix release. If we are still OK for 3.5.4 then I am fine too.
Well if we are worried about any change in behaviour then we shouldn’t make
any changes ever.
The question is whether this is “significant”.
One of my objections to semver is that it only focuses on APIs... so under
semver:
1. No breaking API method signature changes => no major version bump
2. No new API methods => no minor version bump
3. Must be patch
Now in the case of Maven, I argue for semver is a poor fit, largely because
we have multiple APIs, SPIs and UIs each of which have different measures
of breaking changes... but we only have one version number
We need to get 3.5.4 with the jansi fix out... simple bug fixes are fine
for 3.5.4 too.
then we focus on the next version (3.6.x or 4.0.x) and move on... but we
need to move the baseline to Java 8 at this stage and get Java 10 support
better (both of which i’d like to see in a 4.0.x so if we are missing those
then it would be 3.6.x)
Agreed, I'll move it to 3.5.4.
Any other objections from someone else?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
