Report viewer unexpectedly requires a new minimal JPlag version.

[alberth]

I implemented a JPlag check for our local CIF language last November (a few days after releasing version 4.1.0 iirc) and from what I understood it worked well.
Congratulations to you and your team for that.

Last Friday evening I received a mail the online report viewer now wants version 4.2.0, output from the above version is not acceptable. Today I pulled the next version rebased our language on top of it, and built it again. mvn was fine with everything, hopefully the code also still works.

So while today there doesn't seem to be a problem, I am worried about the day that mvn will say "NO".

We don't use JPlag much, around twice a year is my guess. So currently these compatibility problems are detected at the moment new assignments need to be viewed. At that time, results must be returned to the students, so there is very little time to fix things if it's broken. If anything major dies there is no room to handle that.

We are probably one of the few "weird" users, most users will likely find the viewer not accepting the input, download a new version, rerun the checks, and view them.

---

I can fully understand you want to keep moving forward, so stuff breaking down is to be expected. I am fine with that.

What I'd like to ask you is whether it is feasible to make breakage of the tool more predictable. In that way we can update to a new version before results have to be delivered within days.

Some suggestions as an example (I don't know what is feasible for you).

• State a time table of when versions become non-working / non-supported / non-available.
• Keep old report viewers available for a longer time (perhaps with hints "he, you should upgrade to a newer version" if applicable).
• Keep the viewer backwards compatible with older JPlag output.
• Package the report viewer so it can be downloaded and run locally.

Less favorable solutions for us are also an option of course. I hope you don't do that, but I would say in any case it's better to be clear about it beforehand than us finding out afterwards at a horribly inconvenient point in time.

---

Somewhat but not entirely related: When I read the email last week I was surprised that the output was not accepted by the viewer, since JPlag 4.1.0 and Viewer 4.2.0 have the same major version and are thus compatible under a semantic versioning number system.
So clearly I interpreted your version numbers incorrectly.

You may want to state that explicitly somewhere to avoid others falling in that trap.

[tsaglam]

I am sorry if the current release caused trouble. Currently, the deployed versions of the report viewer are tied to the release cycle of the JPlag application. We know this is not ideal, and in the future, we want to move away from that. In the last release we also had to fix some bugs in the report viewer that required to change how the JSON files are structured, thus we had breaking changes.

• State a time table of when versions become non-working / non-supported / non-available.
• Keep old report viewers available for a longer time (perhaps with hints "he, you should upgrade to a newer version" if applicable).

In the future, we want to offer deployed versions of the report viewer for each release with the current URL linking to the most current version. This would allow using old releases after a new one has been released.

• Keep the viewer backwards compatible with older JPlag output.

We are trying to do this as much as possible, unfortunately, I cannot guarantee that this will be always possible.

• Package the report viewer so it can be downloaded and run locally.

While we are currently not packaging the report viewer, it still can be run locally from the sources. Of course, that packaging is favorable.

Somewhat but not entirely related: When I read the email last week I was surprised that the output was not accepted by the viewer, since JPlag 4.1.0 and Viewer 4.2.0 have the same major version and are thus compatible under a semantic versioning number system. So clearly I interpreted your version numbers incorrectly.

You may want to state that explicitly somewhere to avoid others falling in that trap.

You did not misunderstand our versioning, it is just that it (currently) mainly refers to the application and not to the report viewer.
I agree with you, that this is confusing and not a good solution. In future, we should either have a separate version number for the viewer or stick strictly to semantic versioning for both the report viewer and the application.

This is actually an interesting discussion because the question regarding what is actually public API is getting more and more complicated with JPlag, as we tend to have more and more diversification in how our users employ JPlag and what parts of it they use.

I implemented a JPlag check for our local CIF language last November (a few days after releasing version 4.1.0 iirc) and from what I understood it worked well.

A bit of an off-topic question: Did you just implement your own language? Or does your version have more changes?
From your message, I understood that you manage your own fork of JPlag. If you only want your own language, you should be able to achieve that without a fork purely based on an independent language module, the service loader, and dependencies on JPlag. This would guarantee that your generated reports are always compatible and you do not need to adapt the language when JPlag gets new releases (the exception would be a major release that changes the language API).

[alberth]

I am sorry if the current release caused trouble.

No need to be sorry, you're running an open source project, anything can happen any time, including breaking changes.
That is, it's one of the risks in using fast moving open source software.

I had a reply from the teacher using it yesterday, and he said (translated) ".. JPlag has been improved quite a bit, bugs I encountered the previous time have been solved, and the user-interface has been improved. ...". So it works well for us.

Currently, the deployed versions of the report viewer are tied to the release cycle of the JPlag application.

Is the release cycle of JPlag tied to some time schedule? That would work too. The main point I am trying to avoid is that I need to do major changes in the software within the small time window to judge submissions and grade them.

In the future, we want to offer deployed versions of the report viewer for each release with the current URL linking to the most current version.

This would be nice. It wouldn't have saved us this time as the software was broken, but in general this solution should be fine. One thing to consider here is deprecation and shutdown of the "old" viewers at some point.

You did not misunderstand our versioning, it is just that it (currently) mainly refers to the application and not to the report viewer.

Fair enough, the report viewer is a new component, and independent with the checker now. The meaning of version numbers hasn't caught up with that yet.

A bit of an off-topic question: Did you just implement your own language?

Not exactly "just", it has been under development for over a decade :)
Our CIF language is an automaton-based declarative language for developing control systems using synthesis-based engineering. You can find it in the ESCET Eclipse project.

As for connecting it to JPlag: Yes I implemented a new Language to get the CIF language supported in JPlag (although the connection isn't very nice imho but it works and isn't easy to improve).
I also made many other changes in JPlag but you are aware of those as #289 (and several others no directly related to that goal). (Different GH account due to Covid working at home.)

[tsaglam]

I had a reply from the teacher using it yesterday, and he said (translated) ".. JPlag has been improved quite a bit, bugs I encountered the previous time have been solved, and the user-interface has been improved. ...". So it works well for us.

It is very nice to hear that. That means a lot to us!

Is the release cycle of JPlag tied to some time schedule? That would work too. The main point I am trying to avoid is that I need to do major changes in the software within the small time window to judge submissions and grade them.

Currently, no. But if we can reach a point in development where the report viewer is more stable, we want a release cycle that is more predictable.

This would be nice. It wouldn't have saved us this time as the software was broken, but in general this solution should be fine. One thing to consider here is deprecation and shutdown of the "old" viewers at some point.

Yeah, we would probably support something like the x last minor versions and the y last major versions or something similar.

Not exactly "just", it has been under development for over a decade :) Our CIF language is an automaton-based declarative language for developing control systems using synthesis-based engineering. You can find it in the ESCET Eclipse project.

As for connecting it to JPlag: Yes I implemented a new Language to get the CIF language supported in JPlag (although the connection isn't very nice imho but it works and isn't easy to improve). I also made many other changes in JPlag but you are aware of those as #289 (and several others no directly related to that goal). (Different GH account due to Covid working at home.)

Just to be clear, the "just" was referring to the custom language module, not the CIF language! :D
But then I see where the problem stems from, If you maintain a custom version of JPlag, updating from the upstream here upon release will always bare the risk to require manual work. Now I understand why a more predictable release schedule is important to you.

[alberth]

As a (hopefully) less-effort path, if you'd publish the minimum JPlag version required to use the report viewer, I can ask the teacher to check that when exams are near.
In that way they can alert me earlier about needing an update.

Minimal effort is perhaps display that version number at the report viewer entry-page? It seems aware of the version number already.

[tsaglam]

Closed by #1349.