> 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.
I like this suggestion. Either we should be on the side of NO support to
JDK 1.7, or if we say we support JDK1.7, I believe we should be building
against JDK1.7 to make sure we are compliant.
I have a quick clarifying question here - I believe origin of
CASSANDRA-14563 is from the introduction of an API in 2.2 that is
incompatible with 1.7, that has then been manually detected and fixed. Are
you suggesting, going further, we would not support 1.7?
> 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?
>From the current state of build.xml and from the past discussions, I do
believe as well, that we need both JDKs to make a 4.0 release using
‘_build_multi_java’. Bonus would be that, the release would also be able to
run against Java11, but that would be an experimental release.
> I'm not familiar with optional jobs or workflows in CircleCi, do you have
an example of what you mean at hand?
By optional, I was referring to having workflow definitions in place, but
calls to those workflows commented out. Basically similar to what we have
today.
workflows:
version: 2
build_and_run_tests: *default_jobs
#build_and_run_tests: *with_dtest_jobs_only
#build_and_run_tests_java11: *with_dtest_jobs_java11
Jason created CASSANDRA-14609 for this purpose I believe.
> 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 https://cassandra.apache.org/doc/latest/ automatically updated
after each successful trunk build, and have
https://cassandra.apache.org/doc/X.Y versions on the docs in place (which
are only updated after each patch release).
I like all these ideas! I believe we should be able to add a workflow to
test out artifact generation. Will create a JIRA for this. Your suggestions
around auto-update of docs provides a way to keep our website docs
up-to-date. Not sure what it takes to do it though. Will be happy to
explore (as part of separate JIRAs).
Thanks,
Sumanth
On Wed, Sep 5, 2018 at 9:30 PM Mick Semb Wever <m...@apache.org> wrote:
>
>
> > 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 builds.apache.org, 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
> https://cassandra.apache.org/doc/latest/ automatically updated after each
> successful trunk build, and have https://cassandra.apache.org/doc/X.Y
> versions on the docs in place (which are only updated after each patch
> release).
>
> regards,
> Mick
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>
