RDFLib V6 and V7 #2395
Replies: 5 comments 14 replies
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
I very much support sorting out Datasets! |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
Don't forget this almost complete implementation of RDF-Star & SPARQL-Start for RDFLib: #2115 |
Beta Was this translation helpful? Give feedback.
-
|
On type safety and RDF 1.1: here is one discussion spot where type safety, N3, and whether a triple's subject can be a |
Beta Was this translation helpful? Give feedback.
-
|
I have reconsider this a bit. I think this is too ambitious and likely to fail. I think the right answer is just to not worry so much about breaking changes and just try do it as gradually as possible. The downside of this is that we will likely be releasing new major versions every time, but at least we can start fixing some of the interface bugs we have. |
Beta Was this translation helpful? Give feedback.
-
|
Not sure how to jump in here... but me and my organization (http://meemoo.be) use RDFlib actively, so we'll start spending some more time on contributing. Now with respect to the versions and API:
|
Beta Was this translation helpful? Give feedback.
-
This is great, and thanks for the feedback, the more, the better. If you have time, do have a look at the PR that adds guidelines for breaking changes: #2402 - there is also the matrix/gitter channel at https://matrix.to/#/#RDFLib_rdflib:gitter.im where I talk a lot though there is not always that much discussion.
I have thought about this (see details in #2108 and #1841), but we really don't have the capacity for this I think, and it is really very ambitious. I am, however, perfectly happy to accept PRs that add things in non-public namespaces, e.g:
But right now, I think the best option is to just fix the interface directly for most of the issues that exist, though I don't want to deter anyone from trying to get some consensus on a clean API built from scratch, though that will take capacity we don't really have, and I will prioritize actual fixes to the public API.
Yes. I would say it is best to do all of it in one PR, but logical steps would be as you say, but I think it is also important to look at specific examples. #2406 is the first interface break that will be merged I think, as it is almost done, and simple. The clearest description of the problem it addresses is #2404. It breaks the interface very subtly, to the point where maybe it can't be considered breaking it, but it fixes a serious issue which is that there is no way to read data into the default graph (or the closest thing we have to it) from sources that support named graphs. Here the expected behaviour is well established, I still started with a unit test, but it is going into the same PR as the fix. |
Beta Was this translation helpful? Give feedback.
-
|
Those are some good points @aucampia . I've read through #2402 and I totally agree (I would like to see a note on deprecation though). Opposed of what I suggested earlier, I agree that fixing the existing interface with breaking changes is the most realistic and also less confusing. When bundled in a v7 release, the impact will be limited to one (major?) migration for users. |
Beta Was this translation helpful? Give feedback.
-
I will update the PR with some notes on this.
We can only bundle PRs we get, but certainly, I hope we can bundle as many breaking changes as possible at once, though If I had to guess, I would say our next three releases will likely be v7, v8 and v9. |
Beta Was this translation helpful? Give feedback.
-
|
I added this to the PR regarding deprecation: Deprecating functionality
~~~~~~~~~~~~~~~~~~~~~~~~~
To whatever extent possible, classes, functions, variables, or parameters that
will be removed should be marked for deprecation in documentation, and if
possible, should be changed to raise deprecation warnings if used.
There is however no hard requirement that something may only be removed after a
deprecation notice has been added, or only after a release was made with a
deprecation notice.
Consequently, functionality may be removed without it ever being marked as
deprecated.
.. _deprecation_rationale:
Rationale
^^^^^^^^^
Current resource limitations and the backlog of issues make it impractical to
first release or incorporate deprecation notices before making quality of life
changes.
RDFLib uses semantic versioning and provides type hints, and these are the
primary mechanisms for signalling breaking changes to our users.I'm going to merge it this weekend if there is no further feedback. There is an insurmountable backlog, and we have to get cracking if RDFLib is to persist. |
Beta Was this translation helpful? Give feedback.
-
|
Two thoughts (as someone who occasionally maintains an old codebase based originally on much older versions of RDFlib, and applies RDF updates infrequently and in large jumps):
|
Beta Was this translation helpful? Give feedback.
-
It is hard to make guarantees, I think there is lots of work that is needed on the API, even the non-Dataset parts of it, but realistically I don't think it will be changed soon due to resource limitations. My priority is fixing concrete problems, and I will try my best to fix as much as possible with as few breaking changes as possible, but if we get good PRs that break the rest of the API for good reason then it will likely get accepted.
Our mechanisms for signalling breaking changes are our version number, given we follow semantic versioning, our release notes and type hints. Of these, both semantic versioning and type hints provide mechanisms that facilitate automation. If you don't want breaking changes, the best option is to constrain your dependency on RDFLib to a specific major version. This is something you really should be doing anyway. Then, with type hints, if you do decide to upgrade to a new major version, the type hints, in conjunction with a static type checker like mypy, should signal at least some places where code will have to be updated with type errors. |
Beta Was this translation helpful? Give feedback.
-
|
I should also mention that I'm trying to follow conventional commits, and we will possibly go further to ratify this, and use this to generate release notes. With this in place, the release notes should also clearly indicate breaking changes. |
Beta Was this translation helpful? Give feedback.
-
|
After #2406, I thought I'd revisit gromgull's PR #409 (a basic first step towards reworking Dataset) and investigate the ramifications. I posted the resulting PR #2438. Unhappily, some tests are failing. If anyone wishes to review the original work, gromgull's branch is forked from 661a289 - for convenience: here's the comparison |
Beta Was this translation helpful? Give feedback.
-
RDFLib has many open issues and known problems. My strategy for maintenance has been to try and fix as many of them without breaking the API, as breaking the API a little bit in each release is not really reasonable for our users, and if we take that strategy it seems we should rather abandon semantic versioning.
But there are some issues that are rather controversial to fix for V6. Many of them related to Datasets, but there are others also, most of these should show up in these searches:
I was of the opinion that the majority of Dataset issues can be fixed with with the V6 API, but there seems to be disagreement on what the V6 API means, and they seem irreconcilable. Two key examples are:
Datasets andConjunctiveGraphs with non-default graphs without raising any errors #2393These are really quite critical. If we can't handle Datasets correctly, we are not compliant with RDF 1.1 - and if we can't become compliant with RDF 1.1 because the expected behaviour is that we don't support RDF 1.1 - the only sane thing to do is to focus all energy on V7.
I think the right strategy for V7 should be to design a good API that fixes as many problems as we can with the current API and then implement it. I know @gjhiggins has started on some work towards redesign, but there has been little discussion on this and there is no published design.
I don't think trying to fix problems in V6 is productive any more, so I think the responsible thing is to abandon it and start with a new API. If anyone disagrees, please let me know. We should be realistic about V7 though, I think it will take at least a year to get there, if not more, as there are very few people working on it. And once it is released, most people who use RDFLib will have to rewrite their software. We could write a compatibility layer for V6 to use the new API, but I don't think there will be time for that.
CC: @RDFLib/core @RDFLib/core-reviewers
Beta Was this translation helpful? Give feedback.
All reactions