[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Supporting multiple JDKs

> How would we be sure users will never encounter bugs unless we build
> against that JDK? 

Apache Cassandra does not distribute JDK1.7 built releases.

The only way a user could repeat such a bug is if they have built C* themselves.

I don't think the project should be responsible for every possible build combination tom, dick and harry can do.
That's my 2cents anyway. 

And I would suggest to go further and crash the build with JDK1.7 so we can take away the possibility for users to shoot their foot off this way.

> > The time it takes for tests to run is a headache, so to have to run
> dtests four times over makes me grimace.
> It takes only about 25min with default 4x parallelism to run unit tests in
> CircleCI.

I referred to dtests, how would you do this on CircleCI?
Today dtests take 5-9 hours on, not including re-runs for offheap, large, novnode.

> We definitely can build against JDK 8 alone, however from the thread you
> linked and from 9608, we wanted to do a stable release that uses JDK8, and
> an experimental release, which uses JDK8 to build most files, and JDK11 to
> build the Java 11 specific AtomicBTreePartitionBase file.

Currently I'm unclear on how we would make a stable release using only JDK8, maybe their are plans on the table i don't know about?
The current build.xml requires both JDKs to run `ant artifacts`.
That is any release will have compiled in ant all but one class with `_build_multi_java` instead of `_build_java8_only`.

> My proposal is not to necessarily run UTs and DTests against JDK11 always
> with every commit but to have workflows in place that can be used whenever
> we deem necessary.

I'm not familiar with optional jobs or workflows in CircleCi, do you have an example of what you mean at hand?
I like the idea of having a collection of CircleCi workflows, even if I'd rather see less JDKs supported at compile-time.

> I think building the artefacts should be part of the CI build step because patches are not always about java code. 

Off-topic, but what are your thoughts on this? Can we add `ant artifacts`, and the building of the docs, as a separate jobs into the existing default CircleCI workflow? I think we should also be looking into getting automatically updated after each successful trunk build, and have versions on the docs in place (which are only updated after each patch release).


To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxxxx
For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx