search

gpu / JOCL

Java bindings for OpenCL
http://www.jocl.org
Other
187 stars 33 forks source link

JOCL versioning scheme #6

Closed blueberry closed 8 years ago

blueberry commented 8 years ago

Now that the development is more open on github, and the library is quite important to other software that is based on it, it seems to me that the current version scheme could be improved.

I guess that Marco's idea is that minor JOCL versions follow OpenCL versions, so, for example JOCL 0.2.0 supports Opencl 2.0, 0.2.1 is targeted to OpenCL 2.1 etc.

The problem is that there might be (and indeed, ARE) minor bugfixes and development improvements, especially in the development phase, but also once the library is released. In the current scheme, this is solved by adding RC suffix, and then, on top of that, SNAPSHOT, which is not common. Usually, snapshot is for daily builds, and RC is for later stages, when the frozen release is finally tested in the wild.

I think that the major version should follow OpenCL, and then minor bugfix version can be used for incremental improvements.

In that scheme, JOCL 2.0.x would target OpenCL 2.0 standard, and could support much quicker bugfix releases. JOCL 2.1.x would target OpenCL 2.1 etc.

This might not be critical, but I think would enable much clearer development synchronization, and would enable seamless incremental bugfix releases even after the final JOCL release.

gpu commented 8 years ago

I perfectly agree with you here. (In fact, I already mentioned some of these points in https://github.com/gpu/JOCL/pull/4#issuecomment-210399124 (see the second bullet point list, mainly), regarding versioning and the deployment of the native libraries).

I guess that Marco's idea is that minor JOCL versions follow OpenCL versions, so, for example JOCL 0.2.0 supports Opencl 2.0, 0.2.1 is targeted to OpenCL 2.1 etc.

Although I'm doing this for JCuda, I'm not strictly following it for JOCL. There have been versions 0.1.4, for example. It's rather a coincidence that 0.2.0 was the first one to support OpenCL 2.0.

(BTW: The "RC" suffix was an attempt to handle the fact that there may be a new version for which some natives are not available yet - it can not sensibly be deployed to maven as a "final" version without the natives)

However, I also see the problem with the current version numbering. In order to have a more systematic and reliable (and meaningful!) approach, I'd favor Semantic Versioning ( http://semver.org/ ) which is in line with what you described: The first parts of the version number "X.Y.Z" are the OpenCL version. The last digit is used for bugfix releases.

Right now, most (all) issues are related to the build scripts, but once these issues are settled, this pattern could start with the update for OpenCL 2.1. It would lead to JOCL 2.1.0-SNAPSHOT. After the first hiccups, this could become JOCL 2.1.0-RC (tagged) which people could use to build the binaries. Once all binaries are available, it could end as JOCL 2.1.0 in Maven. Bugfixes would then increase the last version number, in the same process.

Nevertheless, there are some other questions regarding the infrastructure. The maven-nar-plugin is still something that I'd like to investigate. And I also considered using https://travis-ci.org/ . If it is possible to obtain the built binaries from travis, then this would immediately solve the issue of missing natives. Do you have any experience with travis? I hope that I can allocate some time soon to give it a try.

gpu commented 8 years ago

(And, by the way: I'll also have to think about development branches. Although there are rarely "multiple, large updates that run in parallel", always working on the master branch may have drawbacks...)

blueberry commented 8 years ago

I have used travis, and the setup was fairly easy, BUT I haven't tried it with native builds.

gpu commented 8 years ago

It seems to offer the option to upload the releases to GitHub: https://docs.travis-ci.com/user/deployment/releases/ If this worked like I wish, it could be possible to tag the state of the native code, then wait for Travis to pick it up, and finally obtain the compiled binaries. But sure, there are maaaany caveats. The native compilation in general (always a hassle - that's why I'm using Java <3), and the dependencies to OpenCL and OpenGL won't make it easier. (However, as these are "standard" libraries, and there are no other dependencies, this could in fact still be managable)

phlip9 commented 8 years ago

However, I also see the problem with the current version numbering. In order to have a more systematic and reliable (and meaningful!) approach, I'd favor Semantic Versioning ( http://semver.org/ ) which is in line with what you described: The first parts of the version number "X.Y.Z" are the OpenCL version. The last digit is used for bugfix releases.

I for one would be on board with semantic versioning. Tracking the OpenCL version might appear more intuitive, but then we can't distinguish between major, minor, and patch changes in JOCL.

gpu commented 8 years ago

Well, I'm not sure whether Khronos has any dedicated versioning rules. For OpenGL, it took until version 3.X until they introduced a deprecation model, and they have the concepts of "core" and "compatibility" profiles. For OpenCL, there have been deprecations right from version 1.1. In any case, the "Patch" part is not used by Khronos, so I think that using "X.Y.P" as the version number of JOCL for OpenCL "X.Y" should be fine. (This may be a bit idealistic, but I think there shouldn't be any major changes in JOCL that do not reflect changes in OpenCL)

gpu commented 8 years ago

Referring to https://github.com/gpu/JOCLBlast/issues/8 :+1:

So this one can be closed now.