Consider 1.0 release

[phillord]

There has been a fair bit of development on the devel branch and it needs merging to main as a new release.

I think this should be the 1.0 release, with the SWRL rules support that I am working on as the current blocker for this.

Thoughts welcome.

[filippodebortoli]

@althonos mentioned in passing here that we could improve the usability of the library by following naming conventions closer to the rust ecosystem and, following the effort done to deprecate traits such as WithIRI, delegate the work of some of the traits introduced in horned to standard traits. Effort in this direction is also done in #74

I think that the introduction of parametric testing (#73) has highlighted the need to thoroughly test the features of horned that have already been implemented to find out (edge) cases that have not yet been covered. See #72 and #76 for examples.

Personally, I would not release 1.0 before fixing #73 and #65 and merging #68, which add desirable features to 'horned'.

On top of this, it would be great if more structured documentation was added. At the moment, some parts of the library lack a clear documentation and the panics/exceptions/assumptions are not always reported. Long-term it could help to have something along the lines of the OWL API tutorial, which could be either baked into the library documentation or published separately.

[phillord]

I don't disagree with any of the things that you suggest to do; I am just aware of perfection being the enemy of the good. We can carry on the 0.x line for ever and find ways of improving it. I think that #73, #65 and #68 would be sensible last things to wait on. Strictly speaking we don't even need to wait for them as they are additions and none should change existing interfaces; but they would be good to have for a future publication.

Documentation, yes, agreed also. Need to think about how to do that so it is testable along with horned.

[filippodebortoli]

I don't disagree with any of the things that you suggest to do; I am just aware of perfection being the enemy of the good. We can carry on the 0.x line for ever and find ways of improving it. I think that #73, #65 and #68 would be sensible last things to wait on. Strictly speaking we don't even need to wait for them as they are additions and none should change existing interfaces; but they would be good to have for a future publication.

Fair point.
We could consider having a systematic "standardization" of the library for version 2.0, as some public interfaces are going to be deprecated and there are going to be breaking changes here and there.
As for 1.0, we can then ensure that #73, #65 and #68 are closed and then proceed, meanwhile trying to improve the state of the documentation.

[phillord]

I think that there are a fair bits of horned that could be standardized. I am aware, for example, that I seem to have written a Visitor three times -- once in the XML renderer, once in the RDF and once in visitor. This is what happens when code is written over too many years.

But, yes, I am quite cool with releasing major versions. Lots of Rust libraries stick at 0.n.n for ever and I can't see the point. If we follow semantic versioning and discover we need to jump through a lot of version number changes then that's fine.

[althonos]

I am aware, for example, that I seem to have written a Visitor three times -- once in the XML renderer, once in the RDF and once in visitor.

And then I wrote a fourth one in an independent crate 😆

I think Rust libraries stick to 0.n until they get at least their API stabilized, because otherwise every method you rename bumps your major version and with every bump you lose some users who do not update.

[phillord]

Yeah, I know. Visitor madness.

I understand your point about the API. In practice with Rust the same thing happens but with minor versions. I have five minor releases behind on quick-xml!

For Horned-OWL, it's clearly a niche thing. In practice I am likely to know most of the people using it personally; I think we can cope with version number changes!

[phillord]

With the addition of SWRL rules, functional syntax and a yet another visitor, I think we now have feature completeness for a 1.0 release of what is current on devel.

Thoughts? If no one objects, I will release and merge to main before the end of the week.

[filippodebortoli]

With the addition of SWRL rules, functional syntax and a yet another visitor, I think we now have feature completeness for a 1.0 release of what is current on devel.

Thoughts? If no one objects, I will release and merge to main before the end of the week.

No objection. :-)

[althonos]

I'll try to review the API quickly tomorrow, if you don't hear back from me feel free to merge! ✌️

[phillord]

Sounds like a plan.

As before, I am not too worried about API changes. If we manage to reach a cadence of two or three major releases a year I would be both surprised and pleased rather than worried.

[phillord]

phillord/pretty_rdf#7

We should probably release pretty_rdf as well.

[phillord]

Documentation updates, pre-commit and everything else.

I will, finally, release 1.0 tomorrow.

[phillord]

2a9da0a

And released!

[althonos]

Congratulations! 🥳

[phillord]

Congratulations! 🥳

Thank you! It's a bit wild after so many years.