Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JPL Version: Upgrade? #46

Closed
ssardina opened this issue Apr 24, 2020 · 4 comments
Closed

JPL Version: Upgrade? #46

ssardina opened this issue Apr 24, 2020 · 4 comments
Assignees
Labels

Comments

@ssardina
Copy link
Contributor

ssardina commented Apr 24, 2020

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
Copy link
Member

JanWielemaker commented Apr 24, 2020

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
Copy link
Contributor

anionic commented Apr 24, 2020

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
Copy link
Contributor Author

ssardina commented Apr 24, 2020

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
Copy link
Contributor Author

ssardina commented Apr 24, 2020

Done in b3c811d and 962cb0f. 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants