SWI-Prolog / packages-jpl

JPL: The Prolog <-> Java interface
BSD 2-Clause "Simplified" License
54 stars 33 forks source link

JPL Version: Upgrade? #46

Closed ssardina closed 4 years ago

ssardina commented 4 years ago

Hi @JanWielemaker

The JPL version is still 7.4.0.

class Version {
    public final int major = 7;
    public final int minor = 4; // jref as blob
    public final int patch = 0;
    public final String status = "alpha";
}

There has been lots of changes since then, the ones I did last year, and the ones now. Last year there were several major bugs fixed, better management of query interface, documentation re-done, etc. This round we added rationals, upgraded Junit and refactored completely into Test Suite, and soon I will push new documentation and refactored several methods in Term. Also 2 key methods were much improved; CMAKE improved.

So, how are you managing versions? 7.4.0 seems matching the previous round of SWI and apperas to be the original JPL, but many things have been done to it. Should we do 8.0.0 (to align better with the current SWI) or at least 7.5.0?

JanWielemaker commented 4 years ago

Most bundled packages have no version and are (thus) implicitly versioned by the overall system. One policy might be to update the version to the current SWI-Prolog version each time there is a (significant?) change. I think that is also the way it got called 7.4.0 at the time.

anionic commented 4 years ago

7.5.0 is already documented at jpl7.org/ReleaseNotes750 so I suggest 7.6 ;-) JPL was originally dreamed to be independent of Prolog implementation, mapping only the classic Prolog term model to & from Java, and its Java-side implementation deliberately resisted adoption of post Java 1.4 features (some nice, but none irresistible), thereby maintaining compatibility with (now very) old JVMs which some deployment environments might be stuck with. Innovations in SWI Prolog 7 prompted a JPL overhaul (from 3.0.3 to 7.0.1) which changed the public API and warranted a rebrand (as "JPL7", in a nod to SWIPL7), but rebranding as "JPL8" seems unjustified, especially as the identity is somewhat embedded (e.g. jpl7.org), and if (as I trust) no JPL7-using applications have been broken, then maybe we should reassure users that the changes, however wonderful, are evolutionary not revolutionary ;-)

ssardina commented 4 years ago

Excellent explanation @anionic , I totally agree! Yes it is independent of SWI and JPL8 would NOT be adequate.

7.6.0 would be good (even 7.5.5 can make it)

Indeed it is NOT revolutionary, it is truly evolutionary.

ssardina commented 4 years ago

Done in b3c811dc71b86a3133e28e742830614a3d772d1b and 962cb0f8e74439423e7a2adf4dbe7299f29c16de. Version to 7.6.0 and included release doc for it with main changes.

BTW, @anionic , I added your nice "historical perspective" to the doc. I think it's good for someone that jumps in, as I did, to have this "big picture" and your summary is just great.