Versioning

[stemann]

@timholy addressed some quite important points in #3. One of which was:

The package version is 4.5.2, which I'm guessing you take from the library version of OpenCV itself. But suppose I want to make a breaking change to the Julia implementation of Mat. So to follow Semver now I need to release v5 of OpenCV.jl?

I know this package was registered as version v4.5.2+ more than two years ago, JuliaRegistries/General#39058 , but personally not knowing any usages of OpenCV.jl, I actually would not object to bumping it back to v0.1-something.

There are zero dependents registered in General: https://juliahub.com/ui/Packages/OpenCV/XIG9o/4.5.3?page=2 https://juliahub.com/ui/Packages/OpenCV/XIG9o/4.5.2?page=2

[stemann]

... and then one could add a VERSION/versioninfo const/method to return the included OpenCV version (4.6.0 currently).

[timholy]

I think it's better to leave it, and just go on to v5. In any case, I now regret having so many 0.x packages; once they're intended for general consumption I think one should release 1.0. We haven't done that for JuliaImages ecosystem yet because at this point there might be some marketing advantage in making it a "big release" but these days I'm starting all new packages at v1.0.0.

[stemann]

It's true that this thing has been out there for general consumption for quite some time - OpenCV.jl should be at version >= 1.0.

Here's another version of the suggestion:

I guess the primary concern is to provide something stable to users.

In this case, there can be users out there without a "compat" entry for OpenCV.jl in their applications - and there can be users with a compat saying something like "4", "4.5", "4.5.2", or "4.5.3" (except for the really restrictive ones).

If we release a new version, 4.5.4, with a "deprecation warning" (saying to use v1 instead - on load), and then re-release the same content as e.g. version 1.0.1 or 1.0.2, then the without-compat users and with-compat users should all get the deprecation warning and their applications will continue to work for years (provided that we do not move too fast wrt. breaking changes for a couple of years).

That would buy some room for potential breaking changes in OpenCV.jl.

It would also avoid the confusion regarding versions of OpenCV (OpenCV_jll.jl) and OpenCV.jl - with them both being at v4 (but at completely different levels of maturity).

In general, I think one should strive for a version 1.0, but I think one should define a couple of goals (early on) for what will constitute a 1.0 - something that is attainable - and then accept that it might take a couple of tries in the v0.x stage to get something that's stable enough (and that one might forget to get that version 0.x.y re-released as v1.0.0 for quite a while...)

[timholy]

I'd ask about this on the #pkgdev slack channel, I've exhausted my expertise and thoughts in this matter. I'd be fine with whatever kind of consensus emerges there.

[ViralBShah]

We have revived the package with the latest opencv, and I currently have tagged it as v4.6. We definitely can't go backwards. However, I didn't need to change any major APIs once @barche generated the new version to get the tests to pass (which are a bit sparse).

Happy to call this v5 if that is the way to go. There is a bump in the Julia version required to the latest LTS.

[stemann]

Nice with a new version.

I think it is better to just keep going with the current (odd) version number.