Apologies for not replying yesterday and thank you, Greg, for answering the
question.
All I could add is that it's a pretty common semantic versioning scheme
[1], although there is no rigorous method of policing it - very often it's
just relying on common sense. Lucene often does add big code chan
Hi Jonathan-
The main branch is the tip of development, and what will eventually become
10.0. It can use a later version of Java, make (some)
non-backwards-compatible API changes, etc. branch_9x tracks the latest 9.x
release, and must run on the version of Java supported by 9.x releases,
must be A
Thanks. What are the rules for what should go into main vs branch_9x?
On Fri, May 5, 2023 at 1:54 PM Dawid Weiss wrote:
>
> The main branch is on Java 17, see build.gradle:
>
> // Minimum Java version required to compile and run Lucene.
> minJavaVersion = JavaVersion.VERSION_17
>
> Also, do
The main branch is on Java 17, see build.gradle:
// Minimum Java version required to compile and run Lucene.
minJavaVersion = JavaVersion.VERSION_17
Also, don't use the default gradle task created by convention; use this one:
./gradlew mavenToLocal
it's an alias but it publishes only a subs
Actually my hack doesn't work, the manifest file changes but the .class
files do not.
On Fri, May 5, 2023 at 12:38 PM Jonathan Ellis wrote:
> `./gradlew publishToMavenLocal` gives me Java 17 class files by default,
> which surprises me since AFAIK 11 is still the minimum to run Lucene.
>
> I hac
`./gradlew publishToMavenLocal` gives me Java 17 class files by default,
which surprises me since AFAIK 11 is still the minimum to run Lucene.
I hacked it to work by editing javac.gradle
sourceCompatibility = JavaVersion.VERSION_11
targetCompatibility = JavaVersion.VERSION_11
Is there a c
