Updating com.vladsch.flexmark version breaks markup filter

Mihai Nita reporter

edited description

2019-06-28T21:16:33+00:00

Chase Tingley

cc @Kuro Kurosaka

The fellow who maintains flexmark puts out releases constantly; it’s hard to keep up. We should be a little careful not regress anything here since there’s a lot of churn in that codebsae.

2019-06-30T05:02:31+00:00

Kuro Kurosaka

I don’t understand the context of this and similar issues. Is the version I picked in my last update (0.35.10) breaking something? Generally speaking no one should update any artifact to their highest versions just because the version is available. We should have a specific reason to do so.

FYI, in https://github.com/vsch/flexmark-java/issues/341#issuecomment-485033418, the author explicitly warned against upgrading beyond version 0.40.0 because there are major changes and some migration work would be required.

I suggest closing this issue as invalid or wontfix.

2019-06-30T08:34:31+00:00

Chase Tingley

It looks like Mihai was running a dependency scanner and flagging things that caused problems.

2019-06-30T16:06:57+00:00

Mihai Nita reporter

“I don’t understand the context of this and similar issues”
…
“Generally speaking no one should update any artifact to their highest versions just because the version is available. We should have a specific reason to do so.”

I think that it is a good “habit” to update libraries with each Okapi release.
We usually try to do this soon after a release, so that we have time to fix issues until the next one.

It is often a lot easier to keep up and make small changes with every release than let them “rot” for several years.

The problem with waiting until we have a specific reason is that it becomes very hard to update
One such example is Lucene. We use 3.3.0 (June 2011), when the last version is 8.1.1 (May 2019), and we have it on the agenda for months now.

If I look at flexmark I can see a few fixes between 35.10 and 50.16 that might be good to have (compatibility with Java 9+, StringIndexOutOfBoundsException, end of line problems, all kind if fixes)
https://github.com/vsch/flexmark-java/blob/master/VERSION.md

I agree that at times it can be a pain in the *** :-)
But I think that skipping many versions waiting for a reason is worse.

If we don’t do this for each Okapi release, what would be good reasons to update?
Security vulnerability, newer JDK compatibility, major bug fixes? What is “major bug”?
I think we need some kind of policy / guidelines / rules for when to do things.

Mihai

2019-07-01T16:29:18+00:00

Mihai Nita reporter

It looks like Mihai was running a dependency scanner and flagging things that caused problems.

A bit more than that :-)
I’ve already updated non-breaking libraries.

Mihai

2019-07-01T16:31:25+00:00

Kuro Kurosaka (BH Lab)

The good reason to update would be to fix a specific bug or implement a new feature. I am afraid I don’t agree on the idea that we should always update all dependent components to the highest available ones, especially for the volunteer based open-source project like Okapi that doesn’t have a dedicated maintenance engineer. But if you are volunteering to do this, I wouldn’t stop you as long as we still maintain the current Java requirement (Java 8 ) and there won’t be any major changes in the parse result. This is important because many users, including clients of Spartan Software which indirectly support the Okapi project, use Okapi in their production systems. They don’t want to see unintended, unnecessary changes in behavior.