Semantic Versioning says nothing about source vs binary compatibility.
The reason for having minor version normally is allow some evolution.
Jena 3.7.0 is not a patch release.
It is highlighted in "heads up" message to users@jena:
https://lists.apache.org/thread.html/5b31a3b6794781f6a02658608444043b5535957a6c94f3728efd8304@%3Cusers.jena.apache.org%3E
What else do you want?
We don't offer or test for binary compatibility (which would also
include the binary compatibility of dependencies because apps may get
them via depending on Jena). We don't claim drop-in replacement of jars
either - exactly the opposite in fact. It causes users problems.
>>>> ... but I would like the
>>>> discussion held and consensus reached before the release goes ahead.
That's rather vague.
There was discussion on JENA-1389.
What extra discussion?
----
It seems me to be rather unhelpful to users to bump the major version
number every time there is a binary change in any of our modules. We
are not Common components. Going back to version-per-module is unhelpful
(users ignored it) as well.
Andy
On 02/04/18 23:22, Claude Warren wrote:
I am not advocating that we create bridge methods in the build as is
mentioned later in the linke I posted above, just asking about the proper
version numbers.
Claude
On Mon, Apr 2, 2018 at 11:20 PM, Claude Warren <cla...@xenei.com> wrote:
Sorry, I should have included a link before:
https://lists.apache.org/list.html?d...@commons.apache.org:
lte=1M:%5Bcollections%5D%20breaking%20changes
On Mon, Apr 2, 2018 at 11:02 AM, Andy Seaborne <a...@apache.org> wrote:
Please see the discussions on the JIRA about source code compatibility.
JENA-1389
https://github.com/apache/jena/pull/362
JENA-1495
https://github.com/apache/jena/pull/368
Where is that other discussion? A link would be helpful.
Andy
On 02/04/18 10:03, Claude Warren wrote:
Should this not be released as a 4.0 version as I think we operate under
semantic versioning and the API is not backwards compatible?
There was a similar discussion over in Commons recently where several of
the functions there were changed to return "this" rather than "void".
Like
our changes here. The decision there was to revert those changes for the
current release and place the "this" returning versions in the upcoming
version number changing release.
as noted in the Commons discussion:
The return type is part of the method signature that Java uses to find
resolve references.
Even changing from void to non-void will cause binary incompatibility.
(Source-wise, that's fine)
I am not certain that I should vote -1 on this issue but I would like the
discussion held and consensus reached before the release goes ahead.
Claude
On Sun, Apr 1, 2018 at 11:03 PM, ajs6f <aj...@apache.org> wrote:
Please vote to approve this release:
[ ] +1 Approve the release
+1
[ ] 0 Don't care
[ ] -1 Don't release, because ...
+ does everything work on OS X?
Yes.
+ are the GPG signatures fine?
Yes.
+ is there a source archive?
Yes.
+ can the source archive really be built?
Yes.
ajs6f
On Mar 29, 2018, at 2:28 PM, Andy Seaborne <a...@apache.org> wrote:
Hi,
Here is a vote on a release of Jena 3.7.0.
This is the first proposed candidate for a 3.7.0 release.
There are process changes.
Deadline:
2018-04-01 22:00 UTC
April 1st!
==== Process Changes
1/
MD5 files are being discouraged because MD5 is not secure. Projects
are
now asked to not publish md5.
There are no md5 files in the proposed dist/jena area - files on Apache
hardware.
There are sha1 and sha512 checksums.
* The sha512 is in Linux sha512sum checkable format.
* The sha1 is whatever maven generated and is the same as will go to
maven central.
Having the sha1 ties the dist/jena artifacts to maven central (as does
the .asc).
There are md5 and sha1 in the proposes maven repo staging area for
sending to maven central. That part of maven is hardwired to md5/sha1
still.
There's a script to setup the sha512.
2/
To establish the proof chain for signed artifacts in /dist/project/, I
have been asked to try out the new META files.
https://checker.apache.org/doc/README.html#ch-meta
There are two files
/dist/jena/META
/dist/jena/META.asc
META says who signs what, and is itself signed by the PMC chair.
==== Release changes
55 JIRA:
https://s.apache.org/jena-3.7.0-jira
== Significant Changes
** Java9: Building and running on a Java9 platform is supported
JENA-1461 - Allow ARQ custom functions to be written in JavaScript
JENA-1389 - Return `this` rather than `void` from Dataset (API change)
JENA-1495 - Return Model from PrefixMapping methods (API change)
JENA-1458, JENA-1483 - Transaction Promotion
JENA-1453 - Lucene indexes using a graph field are smaller
JENA-1490 - Working with Blank Nodes with Fuseki
== Upgrades to libraries (runtime dependencies):
No dependency changes.
==== Release Vote
Everyone, not just committers, is invited to test and vote.
Please download and test the proposed release.
Proposed dist/ area:
https://dist.apache.org/repos/dist/dev/jena/
Keys:
https://svn.apache.org/repos/asf/jena/dist/KEYS
Staging repository:
https://repository.apache.org/content/repositories/orgapache
jena-1022/
Git commit (browser URL):
https://git1-us-west.apache.org/repos/asf?p=jena.git;a=commi
t;h=d4e7063e
Git Commit Hash:
d4e7063e7a6db8ce77699bd0388e1a1bd6816626
Git Commit Tag:
jena-3.7.0-rc1
Please vote to approve this release:
[ ] +1 Approve the release
[ ] 0 Don't care
[ ] -1 Don't release, because ...
This vote will be open until at least
2018-04-01 22:00 UTC
If you expect to check the release but the time limit does not work
for you, please email within the schedule above with an expected time
and we can extend the vote period.
Thanks,
Andy
Checking needed:
+ does everything work on Linux?
+ does everything work on MS Windows?
+ does everything work on OS X?
+ are the GPG signatures fine?
+ are the checksums correct?
+ is there a source archive?
+ can the source archive really be built?
(NB This requires a "mvn install" first time)
+ is there a correct LICENSE and NOTICE file in each artifact
(both source and binary artifacts)?
+ does the NOTICE file contain all necessary attributions?
+ have any licenses of dependencies changed due to upgrades?
if so have LICENSE and NOTICE been upgraded appropriately?
+ does the tag/commit in the SCM contain reproducible sources?
--
I like: Like Like - The likeliest place on the web
<http://like-like.xenei.com>
LinkedIn: http://www.linkedin.com/in/claudewarren
