Mailing List Archive

Lucene 9.2 release
Hi all,

It’s been six weeks or so since we released 9.1, and we have a bunch of nice new features and enhancements piling up in the 9.x branch. I’d like to volunteer to be a release manager for a 9.2 release. I propose to cut a branch this time next week, 10th May.

- Alan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Lucene 9.2 release [ In reply to ]
+1

Thanks Alan!

> On 3. May 2022, at 13:01, Alan Woodward <romseygeek@gmail.com> wrote:
>
> ?Hi all,
>
> It’s been six weeks or so since we released 9.1, and we have a bunch of nice new features and enhancements piling up in the 9.x branch. I’d like to volunteer to be a release manager for a 9.2 release. I propose to cut a branch this time next week, 10th May.
>
> - Alan
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Lucene 9.2 release [ In reply to ]
+1

Thank you Alan!

I wonder if it makes sense to include in the highlighted updates that pull
requests to the github repository no longer require Jira issues?
I'm trying to adjust the contribution workflow more GitHub-oriented and
there is a related issue https://issues.apache.org/jira/browse/LUCENE-10543,
an announcement could be helpful to proceed with it (if it gains basic
agreement among committers).

Tomoko


2022?5?4?(?) 2:26 Ignacio Vera <iverase@gmail.com>:

> +1
>
> Thanks Alan!
>
> > On 3. May 2022, at 13:01, Alan Woodward <romseygeek@gmail.com> wrote:
> >
> > ?Hi all,
> >
> > It’s been six weeks or so since we released 9.1, and we have a bunch of
> nice new features and enhancements piling up in the 9.x branch. I’d like
> to volunteer to be a release manager for a 9.2 release. I propose to cut a
> branch this time next week, 10th May.
> >
> > - Alan
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: dev-help@lucene.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: Lucene 9.2 release [ In reply to ]
Hi Alan,
we have PRs (870 <https://github.com/apache/lucene/pull/870>, 872
<https://github.com/apache/lucene/pull/872>) in progress that involve
format changes to vectors. We would like to merge them for 9.2.
Would it be possible to wait for a couple of days for the branch cut? I can
update here once these PRs are merged.

Thank you in advance

On Wed, May 4, 2022 at 2:59 AM Tomoko Uchida <tomoko.uchida.1111@gmail.com>
wrote:

> +1
>
> Thank you Alan!
>
> I wonder if it makes sense to include in the highlighted updates that pull
> requests to the github repository no longer require Jira issues?
> I'm trying to adjust the contribution workflow more GitHub-oriented and
> there is a related issue
> https://issues.apache.org/jira/browse/LUCENE-10543, an announcement could
> be helpful to proceed with it (if it gains basic agreement among
> committers).
>
> Tomoko
>
>
> 2022?5?4?(?) 2:26 Ignacio Vera <iverase@gmail.com>:
>
>> +1
>>
>> Thanks Alan!
>>
>> > On 3. May 2022, at 13:01, Alan Woodward <romseygeek@gmail.com> wrote:
>> >
>> > ?Hi all,
>> >
>> > It’s been six weeks or so since we released 9.1, and we have a bunch of
>> nice new features and enhancements piling up in the 9.x branch. I’d like
>> to volunteer to be a release manager for a 9.2 release. I propose to cut a
>> branch this time next week, 10th May.
>> >
>> > - Alan
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> > For additional commands, e-mail: dev-help@lucene.apache.org
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
Re: Lucene 9.2 release [ In reply to ]
Hi Mayya,

Yes, that’s fine. I will hold off until you have merged those two PRs.

- Alan

> On 10 May 2022, at 14:24, Mayya Sharipova <mayya.sharipova@elastic.co.INVALID <mailto:mayya.sharipova@elastic.co.INVALID>> wrote:
>
> Hi Alan,
> we have PRs (870 <https://github.com/apache/lucene/pull/870>, 872 <https://github.com/apache/lucene/pull/872>) in progress that involve format changes to vectors. We would like to merge them for 9.2.
> Would it be possible to wait for a couple of days for the branch cut? I can update here once these PRs are merged.
>
> Thank you in advance
>
> On Wed, May 4, 2022 at 2:59 AM Tomoko Uchida <tomoko.uchida.1111@gmail.com <mailto:tomoko.uchida.1111@gmail.com>> wrote:
> +1
>
> Thank you Alan!
>
> I wonder if it makes sense to include in the highlighted updates that pull requests to the github repository no longer require Jira issues?
> I'm trying to adjust the contribution workflow more GitHub-oriented and there is a related issue https://issues.apache.org/jira/browse/LUCENE-10543 <https://issues.apache.org/jira/browse/LUCENE-10543>, an announcement could be helpful to proceed with it (if it gains basic agreement among committers).
>
> Tomoko
>
>
> 2022?5?4?(?) 2:26 Ignacio Vera <iverase@gmail.com <mailto:iverase@gmail.com>>:
> +1
>
> Thanks Alan!
>
> > On 3. May 2022, at 13:01, Alan Woodward <romseygeek@gmail.com <mailto:romseygeek@gmail.com>> wrote:
> >
> > ?Hi all,
> >
> > It’s been six weeks or so since we released 9.1, and we have a bunch of nice new features and enhancements piling up in the 9.x branch. I’d like to volunteer to be a release manager for a 9.2 release. I propose to cut a branch this time next week, 10th May.
> >
> > - Alan
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <mailto:dev-unsubscribe@lucene.apache.org>
> > For additional commands, e-mail: dev-help@lucene.apache.org <mailto:dev-help@lucene.apache.org>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <mailto:dev-unsubscribe@lucene.apache.org>
> For additional commands, e-mail: dev-help@lucene.apache.org <mailto:dev-help@lucene.apache.org>
>
Re: Lucene 9.2 release [ In reply to ]
Hi Alan,
I want to report that all scheduled changes to vectors' format have been
merged to 9.x, and from our side we are good to proceed with the 9.2
release.
Sorry for the delay and thank you for waiting.

On Tue, May 10, 2022 at 9:24 AM Mayya Sharipova <mayya.sharipova@elastic.co>
wrote:

> Hi Alan,
> we have PRs (870 <https://github.com/apache/lucene/pull/870>, 872
> <https://github.com/apache/lucene/pull/872>) in progress that involve
> format changes to vectors. We would like to merge them for 9.2.
> Would it be possible to wait for a couple of days for the branch cut? I
> can update here once these PRs are merged.
>
> Thank you in advance
>
> On Wed, May 4, 2022 at 2:59 AM Tomoko Uchida <tomoko.uchida.1111@gmail.com>
> wrote:
>
>> +1
>>
>> Thank you Alan!
>>
>> I wonder if it makes sense to include in the highlighted updates that
>> pull requests to the github repository no longer require Jira issues?
>> I'm trying to adjust the contribution workflow more GitHub-oriented and
>> there is a related issue
>> https://issues.apache.org/jira/browse/LUCENE-10543, an announcement
>> could be helpful to proceed with it (if it gains basic agreement among
>> committers).
>>
>> Tomoko
>>
>>
>> 2022?5?4?(?) 2:26 Ignacio Vera <iverase@gmail.com>:
>>
>>> +1
>>>
>>> Thanks Alan!
>>>
>>> > On 3. May 2022, at 13:01, Alan Woodward <romseygeek@gmail.com> wrote:
>>> >
>>> > ?Hi all,
>>> >
>>> > It’s been six weeks or so since we released 9.1, and we have a bunch
>>> of nice new features and enhancements piling up in the 9.x branch. I’d
>>> like to volunteer to be a release manager for a 9.2 release. I propose to
>>> cut a branch this time next week, 10th May.
>>> >
>>> > - Alan
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> > For additional commands, e-mail: dev-help@lucene.apache.org
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>>
Re: Lucene 9.2 release [ In reply to ]
Hi all,

I was ill at the end of last week so this took a little longer than expected! I’ve started the release process using the wizard, which has found some broken links in javadoc. Somewhat strangely, these broken links don’t seem to be found when not running from a clean checkout, which suggests that there’s something being cached somewhere? I’ll open a PR to fix the immediate problem but I’ll see if I can work out what’s going on with those links not being picked up during normal development - it’s not ideal if we only find these problems when preparing a release.

- A

> On 12 May 2022, at 21:11, Mayya Sharipova <mayya.sharipova@elastic.co.INVALID <mailto:mayya.sharipova@elastic.co.INVALID>> wrote:
>
> Hi Alan,
> I want to report that all scheduled changes to vectors' format have been merged to 9.x, and from our side we are good to proceed with the 9.2 release.
> Sorry for the delay and thank you for waiting.
>
> On Tue, May 10, 2022 at 9:24 AM Mayya Sharipova <mayya.sharipova@elastic.co <mailto:mayya.sharipova@elastic.co>> wrote:
> Hi Alan,
> we have PRs (870 <https://github.com/apache/lucene/pull/870>, 872 <https://github.com/apache/lucene/pull/872>) in progress that involve format changes to vectors. We would like to merge them for 9.2.
> Would it be possible to wait for a couple of days for the branch cut? I can update here once these PRs are merged.
>
> Thank you in advance
>
> On Wed, May 4, 2022 at 2:59 AM Tomoko Uchida <tomoko.uchida.1111@gmail.com <mailto:tomoko.uchida.1111@gmail.com>> wrote:
> +1
>
> Thank you Alan!
>
> I wonder if it makes sense to include in the highlighted updates that pull requests to the github repository no longer require Jira issues?
> I'm trying to adjust the contribution workflow more GitHub-oriented and there is a related issue https://issues.apache.org/jira/browse/LUCENE-10543 <https://issues.apache.org/jira/browse/LUCENE-10543>, an announcement could be helpful to proceed with it (if it gains basic agreement among committers).
>
> Tomoko
>
>
> 2022?5?4?(?) 2:26 Ignacio Vera <iverase@gmail.com <mailto:iverase@gmail.com>>:
> +1
>
> Thanks Alan!
>
> > On 3. May 2022, at 13:01, Alan Woodward <romseygeek@gmail.com <mailto:romseygeek@gmail.com>> wrote:
> >
> > ?Hi all,
> >
> > It’s been six weeks or so since we released 9.1, and we have a bunch of nice new features and enhancements piling up in the 9.x branch. I’d like to volunteer to be a release manager for a 9.2 release. I propose to cut a branch this time next week, 10th May.
> >
> > - Alan
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <mailto:dev-unsubscribe@lucene.apache.org>
> > For additional commands, e-mail: dev-help@lucene.apache.org <mailto:dev-help@lucene.apache.org>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <mailto:dev-unsubscribe@lucene.apache.org>
> For additional commands, e-mail: dev-help@lucene.apache.org <mailto:dev-help@lucene.apache.org>
>
Re: Lucene 9.2 release [ In reply to ]
It shouldn't be the case. Either something is misconfigured or wrong.

- you can try to diff a clean run with a non-clean run and add
--console=plain and possible --info to gradlew - this will emit more
information about tasks and whether they ran or not,
- different jvms producing different javadoc? Could this be the cause?

D.

On Mon, May 16, 2022 at 12:50 PM Alan Woodward <romseygeek@gmail.com> wrote:

> Hi all,
>
> I was ill at the end of last week so this took a little longer than
> expected! I’ve started the release process using the wizard, which has
> found some broken links in javadoc. Somewhat strangely, these broken links
> don’t seem to be found when not running from a clean checkout, which
> suggests that there’s something being cached somewhere? I’ll open a PR to
> fix the immediate problem but I’ll see if I can work out what’s going on
> with those links not being picked up during normal development - it’s not
> ideal if we only find these problems when preparing a release.
>
> - A
>
> On 12 May 2022, at 21:11, Mayya Sharipova <
> mayya.sharipova@elastic.co.INVALID> wrote:
>
> Hi Alan,
> I want to report that all scheduled changes to vectors' format have been
> merged to 9.x, and from our side we are good to proceed with the 9.2
> release.
> Sorry for the delay and thank you for waiting.
>
> On Tue, May 10, 2022 at 9:24 AM Mayya Sharipova <
> mayya.sharipova@elastic.co> wrote:
>
>> Hi Alan,
>> we have PRs (870 <https://github.com/apache/lucene/pull/870>, 872
>> <https://github.com/apache/lucene/pull/872>) in progress that involve
>> format changes to vectors. We would like to merge them for 9.2.
>> Would it be possible to wait for a couple of days for the branch cut? I
>> can update here once these PRs are merged.
>>
>> Thank you in advance
>>
>> On Wed, May 4, 2022 at 2:59 AM Tomoko Uchida <
>> tomoko.uchida.1111@gmail.com> wrote:
>>
>>> +1
>>>
>>> Thank you Alan!
>>>
>>> I wonder if it makes sense to include in the highlighted updates that
>>> pull requests to the github repository no longer require Jira issues?
>>> I'm trying to adjust the contribution workflow more GitHub-oriented and
>>> there is a related issue
>>> https://issues.apache.org/jira/browse/LUCENE-10543, an announcement
>>> could be helpful to proceed with it (if it gains basic agreement among
>>> committers).
>>>
>>> Tomoko
>>>
>>>
>>> 2022?5?4?(?) 2:26 Ignacio Vera <iverase@gmail.com>:
>>>
>>>> +1
>>>>
>>>> Thanks Alan!
>>>>
>>>> > On 3. May 2022, at 13:01, Alan Woodward <romseygeek@gmail.com> wrote:
>>>> >
>>>> > ?Hi all,
>>>> >
>>>> > It’s been six weeks or so since we released 9.1, and we have a bunch
>>>> of nice new features and enhancements piling up in the 9.x branch. I’d
>>>> like to volunteer to be a release manager for a 9.2 release. I propose to
>>>> cut a branch this time next week, 10th May.
>>>> >
>>>> > - Alan
>>>> > ---------------------------------------------------------------------
>>>> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>> > For additional commands, e-mail: dev-help@lucene.apache.org
>>>> >
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>
>>>>
>
Re: Lucene 9.2 release [ In reply to ]
On Mon, May 16, 2022 at 9:28 AM Dawid Weiss <dawid.weiss@gmail.com> wrote:
> - different jvms producing different javadoc? Could this be the cause?
>

This is it, it is always a bug when javadoc produces broken links like
this. It happens "at release time" because otherwise nobody is messing
with java 11.

Newer java versions won't make a broken link, you just won't have a link at all.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
RE: Lucene 9.2 release [ In reply to ]
Hi,

Jenkins runs with JDK 11, so it should hit that problem. Was this in smoke tester or during normal gradle build?

Uwe

-----
Uwe Schindler
Achterdiek 19, D-28357 Bremen
https://www.thetaphi.de
eMail: uwe@thetaphi.de

> -----Original Message-----
> From: Robert Muir <rcmuir@gmail.com>
> Sent: Monday, May 16, 2022 3:30 PM
> To: dev@lucene.apache.org
> Subject: Re: Lucene 9.2 release
>
> On Mon, May 16, 2022 at 9:28 AM Dawid Weiss <dawid.weiss@gmail.com>
> wrote:
> > - different jvms producing different javadoc? Could this be the cause?
> >
>
> This is it, it is always a bug when javadoc produces broken links like
> this. It happens "at release time" because otherwise nobody is messing
> with java 11.
>
> Newer java versions won't make a broken link, you just won't have a link at all.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Lucene 9.2 release [ In reply to ]
It was part of the release process, which runs with Java 11. It should be fixed now.

> Newer java versions won't make a broken link, you just won't have a link at all.

This seems a bit of a shame, as some of the problems were genuine API bugs - public methods with package-private parameter classes, and so on. Do we have other ways of detecting these? Warning levels on the compiler maybe?

> On 16 May 2022, at 18:14, Uwe Schindler <uwe@thetaphi.de> wrote:
>
> Hi,
>
> Jenkins runs with JDK 11, so it should hit that problem. Was this in smoke tester or during normal gradle build?
>
> Uwe
>
> -----
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> https://www.thetaphi.de
> eMail: uwe@thetaphi.de
>
>> -----Original Message-----
>> From: Robert Muir <rcmuir@gmail.com>
>> Sent: Monday, May 16, 2022 3:30 PM
>> To: dev@lucene.apache.org
>> Subject: Re: Lucene 9.2 release
>>
>> On Mon, May 16, 2022 at 9:28 AM Dawid Weiss <dawid.weiss@gmail.com>
>> wrote:
>>> - different jvms producing different javadoc? Could this be the cause?
>>>
>>
>> This is it, it is always a bug when javadoc produces broken links like
>> this. It happens "at release time" because otherwise nobody is messing
>> with java 11.
>>
>> Newer java versions won't make a broken link, you just won't have a link at all.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Lucene 9.2 release [ In reply to ]
I traced what tasks are actually executed in "gradlew check" task from the
GitHub Actions log.
Not fully sure but javadocs/documentation validation (such as the broken
links check) could be possibly omitted from it?
If so, I think we should include it in the check task... I'll look at it;
please correct me if I'm missing something.

Tomoko


2022?5?17?(?) 18:59 Alan Woodward <romseygeek@gmail.com>:

> It was part of the release process, which runs with Java 11. It should be
> fixed now.
>
> > Newer java versions won't make a broken link, you just won't have a link
> at all.
>
> This seems a bit of a shame, as some of the problems were genuine API bugs
> - public methods with package-private parameter classes, and so on. Do we
> have other ways of detecting these? Warning levels on the compiler maybe?
>
> > On 16 May 2022, at 18:14, Uwe Schindler <uwe@thetaphi.de> wrote:
> >
> > Hi,
> >
> > Jenkins runs with JDK 11, so it should hit that problem. Was this in
> smoke tester or during normal gradle build?
> >
> > Uwe
> >
> > -----
> > Uwe Schindler
> > Achterdiek 19, D-28357 Bremen
> > https://www.thetaphi.de
> > eMail: uwe@thetaphi.de
> >
> >> -----Original Message-----
> >> From: Robert Muir <rcmuir@gmail.com>
> >> Sent: Monday, May 16, 2022 3:30 PM
> >> To: dev@lucene.apache.org
> >> Subject: Re: Lucene 9.2 release
> >>
> >> On Mon, May 16, 2022 at 9:28 AM Dawid Weiss <dawid.weiss@gmail.com>
> >> wrote:
> >>> - different jvms producing different javadoc? Could this be the cause?
> >>>
> >>
> >> This is it, it is always a bug when javadoc produces broken links like
> >> this. It happens "at release time" because otherwise nobody is messing
> >> with java 11.
> >>
> >> Newer java versions won't make a broken link, you just won't have a
> link at all.
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >> For additional commands, e-mail: dev-help@lucene.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: dev-help@lucene.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: Lucene 9.2 release [ In reply to ]
Sorry - my mistake. It's included in the check task on both the main and 9x
branches. Humans are unlikely to run it on 9x branch, but CI servers
(Jenkins and GitHub Actions) should run it every day on Java 11 at the
clean checkout.

./gradlew check --dry-run | grep checkBrokenLinks
:lucene:documentation:checkBrokenLinks SKIPPED

Tomoko


2022?5?17?(?) 20:36 Tomoko Uchida <tomoko.uchida.1111@gmail.com>:

> I traced what tasks are actually executed in "gradlew check" task from the
> GitHub Actions log.
> Not fully sure but javadocs/documentation validation (such as the broken
> links check) could be possibly omitted from it?
> If so, I think we should include it in the check task... I'll look at it;
> please correct me if I'm missing something.
>
> Tomoko
>
>
> 2022?5?17?(?) 18:59 Alan Woodward <romseygeek@gmail.com>:
>
>> It was part of the release process, which runs with Java 11. It should
>> be fixed now.
>>
>> > Newer java versions won't make a broken link, you just won't have a
>> link at all.
>>
>> This seems a bit of a shame, as some of the problems were genuine API
>> bugs - public methods with package-private parameter classes, and so on.
>> Do we have other ways of detecting these? Warning levels on the compiler
>> maybe?
>>
>> > On 16 May 2022, at 18:14, Uwe Schindler <uwe@thetaphi.de> wrote:
>> >
>> > Hi,
>> >
>> > Jenkins runs with JDK 11, so it should hit that problem. Was this in
>> smoke tester or during normal gradle build?
>> >
>> > Uwe
>> >
>> > -----
>> > Uwe Schindler
>> > Achterdiek 19, D-28357 Bremen
>> > https://www.thetaphi.de
>> > eMail: uwe@thetaphi.de
>> >
>> >> -----Original Message-----
>> >> From: Robert Muir <rcmuir@gmail.com>
>> >> Sent: Monday, May 16, 2022 3:30 PM
>> >> To: dev@lucene.apache.org
>> >> Subject: Re: Lucene 9.2 release
>> >>
>> >> On Mon, May 16, 2022 at 9:28 AM Dawid Weiss <dawid.weiss@gmail.com>
>> >> wrote:
>> >>> - different jvms producing different javadoc? Could this be the cause?
>> >>>
>> >>
>> >> This is it, it is always a bug when javadoc produces broken links like
>> >> this. It happens "at release time" because otherwise nobody is messing
>> >> with java 11.
>> >>
>> >> Newer java versions won't make a broken link, you just won't have a
>> link at all.
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> >> For additional commands, e-mail: dev-help@lucene.apache.org
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> > For additional commands, e-mail: dev-help@lucene.apache.org
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
Re: Lucene 9.2 release [ In reply to ]
On Tue, May 17, 2022 at 5:59 AM Alan Woodward <romseygeek@gmail.com> wrote:
>
> It was part of the release process, which runs with Java 11. It should be fixed now.
>
> > Newer java versions won't make a broken link, you just won't have a link at all.
>
> This seems a bit of a shame, as some of the problems were genuine API bugs - public methods with package-private parameter classes, and so on. Do we have other ways of detecting these? Warning levels on the compiler maybe?
>

Agreed, although we are really abusing the functionality. Main purpose
of the check is to prevent broken links (HTTP 404 from the website,
etc).

I don't know of a built-in way to do the exact check. One idea is to
add a check to our custom doclet:
https://github.com/apache/lucene/blob/main/dev-tools/missing-doclet/src/main/java/org/apache/lucene/missingdoclet/MissingDoclet.java

Element has getModifiers() which should be enough to check the
visibility of things like parameters and return type. However, we
might have to restructure the checker a bit, for most modules we
aren't even descending into "parameter" level checks today: most
modules are only enforcing at class level.

Honestly it is still probably the wrong tool for this, as the issue
really isn't javadocs related. But the doclet is a hammer we can use
for checks like this.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Lucene 9.2 release [ In reply to ]
> I’ve started the release process using the wizard, which has found some
broken links in javadoc.

I'm just interested in this point - as Uwe pointed out, Jenkins servers
(and also GitHub Actions I think) should hit the problem as they run on
branch_9x and Java 11 on a regular basis.
Could you let me know the exact command or the corresponding wizard lines?
If there are gaps between the nightly build and the wizard, we could try to
fill the gap.

Tomoko


2022?5?17?(?) 21:54 Robert Muir <rcmuir@gmail.com>:

> On Tue, May 17, 2022 at 5:59 AM Alan Woodward <romseygeek@gmail.com>
> wrote:
> >
> > It was part of the release process, which runs with Java 11. It should
> be fixed now.
> >
> > > Newer java versions won't make a broken link, you just won't have a
> link at all.
> >
> > This seems a bit of a shame, as some of the problems were genuine API
> bugs - public methods with package-private parameter classes, and so on.
> Do we have other ways of detecting these? Warning levels on the compiler
> maybe?
> >
>
> Agreed, although we are really abusing the functionality. Main purpose
> of the check is to prevent broken links (HTTP 404 from the website,
> etc).
>
> I don't know of a built-in way to do the exact check. One idea is to
> add a check to our custom doclet:
>
> https://github.com/apache/lucene/blob/main/dev-tools/missing-doclet/src/main/java/org/apache/lucene/missingdoclet/MissingDoclet.java
>
> Element has getModifiers() which should be enough to check the
> visibility of things like parameters and return type. However, we
> might have to restructure the checker a bit, for most modules we
> aren't even descending into "parameter" level checks today: most
> modules are only enforcing at class level.
>
> Honestly it is still probably the wrong tool for this, as the issue
> really isn't javadocs related. But the doclet is a hammer we can use
> for checks like this.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: Lucene 9.2 release [ In reply to ]
I think the issue will boil down to exact version of java 11. It has to be
the one with the javadocs bug that emits broken links in this situation.

On Tue, May 17, 2022, 8:39 PM Tomoko Uchida <tomoko.uchida.1111@gmail.com>
wrote:

> > I’ve started the release process using the wizard, which has found some
> broken links in javadoc.
>
> I'm just interested in this point - as Uwe pointed out, Jenkins servers
> (and also GitHub Actions I think) should hit the problem as they run on
> branch_9x and Java 11 on a regular basis.
> Could you let me know the exact command or the corresponding wizard lines?
> If there are gaps between the nightly build and the wizard, we could try to
> fill the gap.
>
> Tomoko
>
>
> 2022?5?17?(?) 21:54 Robert Muir <rcmuir@gmail.com>:
>
>> On Tue, May 17, 2022 at 5:59 AM Alan Woodward <romseygeek@gmail.com>
>> wrote:
>> >
>> > It was part of the release process, which runs with Java 11. It should
>> be fixed now.
>> >
>> > > Newer java versions won't make a broken link, you just won't have a
>> link at all.
>> >
>> > This seems a bit of a shame, as some of the problems were genuine API
>> bugs - public methods with package-private parameter classes, and so on.
>> Do we have other ways of detecting these? Warning levels on the compiler
>> maybe?
>> >
>>
>> Agreed, although we are really abusing the functionality. Main purpose
>> of the check is to prevent broken links (HTTP 404 from the website,
>> etc).
>>
>> I don't know of a built-in way to do the exact check. One idea is to
>> add a check to our custom doclet:
>>
>> https://github.com/apache/lucene/blob/main/dev-tools/missing-doclet/src/main/java/org/apache/lucene/missingdoclet/MissingDoclet.java
>>
>> Element has getModifiers() which should be enough to check the
>> visibility of things like parameters and return type. However, we
>> might have to restructure the checker a bit, for most modules we
>> aren't even descending into "parameter" level checks today: most
>> modules are only enforcing at class level.
>>
>> Honestly it is still probably the wrong tool for this, as the issue
>> really isn't javadocs related. But the doclet is a hammer we can use
>> for checks like this.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
Re: Lucene 9.2 release [ In reply to ]
> I think the issue will boil down to exact version of java 11. It has to
be the one with the javadocs bug that emits broken links in this situation.

Yes - I think it'd be great if we can detect bugs in our code and the
language itself we depend on (Java 11) on nightly CI builds, not on the
release process (if possible!) :)

Tomoko


2022?5?18?(?) 9:46 Robert Muir <rcmuir@gmail.com>:

> I think the issue will boil down to exact version of java 11. It has to be
> the one with the javadocs bug that emits broken links in this situation.
>
> On Tue, May 17, 2022, 8:39 PM Tomoko Uchida <tomoko.uchida.1111@gmail.com>
> wrote:
>
>> > I’ve started the release process using the wizard, which has found some
>> broken links in javadoc.
>>
>> I'm just interested in this point - as Uwe pointed out, Jenkins servers
>> (and also GitHub Actions I think) should hit the problem as they run on
>> branch_9x and Java 11 on a regular basis.
>> Could you let me know the exact command or the corresponding wizard
>> lines? If there are gaps between the nightly build and the wizard, we could
>> try to fill the gap.
>>
>> Tomoko
>>
>>
>> 2022?5?17?(?) 21:54 Robert Muir <rcmuir@gmail.com>:
>>
>>> On Tue, May 17, 2022 at 5:59 AM Alan Woodward <romseygeek@gmail.com>
>>> wrote:
>>> >
>>> > It was part of the release process, which runs with Java 11. It
>>> should be fixed now.
>>> >
>>> > > Newer java versions won't make a broken link, you just won't have a
>>> link at all.
>>> >
>>> > This seems a bit of a shame, as some of the problems were genuine API
>>> bugs - public methods with package-private parameter classes, and so on.
>>> Do we have other ways of detecting these? Warning levels on the compiler
>>> maybe?
>>> >
>>>
>>> Agreed, although we are really abusing the functionality. Main purpose
>>> of the check is to prevent broken links (HTTP 404 from the website,
>>> etc).
>>>
>>> I don't know of a built-in way to do the exact check. One idea is to
>>> add a check to our custom doclet:
>>>
>>> https://github.com/apache/lucene/blob/main/dev-tools/missing-doclet/src/main/java/org/apache/lucene/missingdoclet/MissingDoclet.java
>>>
>>> Element has getModifiers() which should be enough to check the
>>> visibility of things like parameters and return type. However, we
>>> might have to restructure the checker a bit, for most modules we
>>> aren't even descending into "parameter" level checks today: most
>>> modules are only enforcing at class level.
>>>
>>> Honestly it is still probably the wrong tool for this, as the issue
>>> really isn't javadocs related. But the doclet is a hammer we can use
>>> for checks like this.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>>
Re: Lucene 9.2 release [ In reply to ]
But that's not the case at all. I suspect it is simply that Alan used
an older version of java 11, one that has a javadocs bug.

On Tue, May 17, 2022 at 11:26 PM Tomoko Uchida
<tomoko.uchida.1111@gmail.com> wrote:
>
> > I think the issue will boil down to exact version of java 11. It has to be the one with the javadocs bug that emits broken links in this situation.
>
> Yes - I think it'd be great if we can detect bugs in our code and the language itself we depend on (Java 11) on nightly CI builds, not on the release process (if possible!) :)
>
> Tomoko
>
>
> 2022?5?18?(?) 9:46 Robert Muir <rcmuir@gmail.com>:
>>
>> I think the issue will boil down to exact version of java 11. It has to be the one with the javadocs bug that emits broken links in this situation.
>>
>> On Tue, May 17, 2022, 8:39 PM Tomoko Uchida <tomoko.uchida.1111@gmail.com> wrote:
>>>
>>> > I’ve started the release process using the wizard, which has found some broken links in javadoc.
>>>
>>> I'm just interested in this point - as Uwe pointed out, Jenkins servers (and also GitHub Actions I think) should hit the problem as they run on branch_9x and Java 11 on a regular basis.
>>> Could you let me know the exact command or the corresponding wizard lines? If there are gaps between the nightly build and the wizard, we could try to fill the gap.
>>>
>>> Tomoko
>>>
>>>
>>> 2022?5?17?(?) 21:54 Robert Muir <rcmuir@gmail.com>:
>>>>
>>>> On Tue, May 17, 2022 at 5:59 AM Alan Woodward <romseygeek@gmail.com> wrote:
>>>> >
>>>> > It was part of the release process, which runs with Java 11. It should be fixed now.
>>>> >
>>>> > > Newer java versions won't make a broken link, you just won't have a link at all.
>>>> >
>>>> > This seems a bit of a shame, as some of the problems were genuine API bugs - public methods with package-private parameter classes, and so on. Do we have other ways of detecting these? Warning levels on the compiler maybe?
>>>> >
>>>>
>>>> Agreed, although we are really abusing the functionality. Main purpose
>>>> of the check is to prevent broken links (HTTP 404 from the website,
>>>> etc).
>>>>
>>>> I don't know of a built-in way to do the exact check. One idea is to
>>>> add a check to our custom doclet:
>>>> https://github.com/apache/lucene/blob/main/dev-tools/missing-doclet/src/main/java/org/apache/lucene/missingdoclet/MissingDoclet.java
>>>>
>>>> Element has getModifiers() which should be enough to check the
>>>> visibility of things like parameters and return type. However, we
>>>> might have to restructure the checker a bit, for most modules we
>>>> aren't even descending into "parameter" level checks today: most
>>>> modules are only enforcing at class level.
>>>>
>>>> Honestly it is still probably the wrong tool for this, as the issue
>>>> really isn't javadocs related. But the doclet is a hammer we can use
>>>> for checks like this.
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Lucene 9.2 release [ In reply to ]
I'm unable to even download an old enough jdk version to reproduce the
javadocs bugs Alan hits. The oldest you can get from adoptopenjdk
archives are 4-year old java 11 versions, still not old enough.

There's no value to testing such broken old versions (e.g. 11.0.1) in
our CI when we've already done exactly that, years ago, and reported
bugs back and iterated. ppl should use most recent versions (e.g.
11.0.15), especially for smoketesting and development. It is expected
that tests may fail, build may fail, you might hit SIGSEGV from
compiler, etc, if you use old buggy java 11.0.1 or similar.
I'm also ok with failing hard on the build if someone tries to use
such old stuff.

On Tue, May 17, 2022 at 11:39 PM Robert Muir <rcmuir@gmail.com> wrote:
>
> But that's not the case at all. I suspect it is simply that Alan used
> an older version of java 11, one that has a javadocs bug.
>
> On Tue, May 17, 2022 at 11:26 PM Tomoko Uchida
> <tomoko.uchida.1111@gmail.com> wrote:
> >
> > > I think the issue will boil down to exact version of java 11. It has to be the one with the javadocs bug that emits broken links in this situation.
> >
> > Yes - I think it'd be great if we can detect bugs in our code and the language itself we depend on (Java 11) on nightly CI builds, not on the release process (if possible!) :)
> >
> > Tomoko
> >
> >
> > 2022?5?18?(?) 9:46 Robert Muir <rcmuir@gmail.com>:
> >>
> >> I think the issue will boil down to exact version of java 11. It has to be the one with the javadocs bug that emits broken links in this situation.
> >>
> >> On Tue, May 17, 2022, 8:39 PM Tomoko Uchida <tomoko.uchida.1111@gmail.com> wrote:
> >>>
> >>> > I’ve started the release process using the wizard, which has found some broken links in javadoc.
> >>>
> >>> I'm just interested in this point - as Uwe pointed out, Jenkins servers (and also GitHub Actions I think) should hit the problem as they run on branch_9x and Java 11 on a regular basis.
> >>> Could you let me know the exact command or the corresponding wizard lines? If there are gaps between the nightly build and the wizard, we could try to fill the gap.
> >>>
> >>> Tomoko
> >>>
> >>>
> >>> 2022?5?17?(?) 21:54 Robert Muir <rcmuir@gmail.com>:
> >>>>
> >>>> On Tue, May 17, 2022 at 5:59 AM Alan Woodward <romseygeek@gmail.com> wrote:
> >>>> >
> >>>> > It was part of the release process, which runs with Java 11. It should be fixed now.
> >>>> >
> >>>> > > Newer java versions won't make a broken link, you just won't have a link at all.
> >>>> >
> >>>> > This seems a bit of a shame, as some of the problems were genuine API bugs - public methods with package-private parameter classes, and so on. Do we have other ways of detecting these? Warning levels on the compiler maybe?
> >>>> >
> >>>>
> >>>> Agreed, although we are really abusing the functionality. Main purpose
> >>>> of the check is to prevent broken links (HTTP 404 from the website,
> >>>> etc).
> >>>>
> >>>> I don't know of a built-in way to do the exact check. One idea is to
> >>>> add a check to our custom doclet:
> >>>> https://github.com/apache/lucene/blob/main/dev-tools/missing-doclet/src/main/java/org/apache/lucene/missingdoclet/MissingDoclet.java
> >>>>
> >>>> Element has getModifiers() which should be enough to check the
> >>>> visibility of things like parameters and return type. However, we
> >>>> might have to restructure the checker a bit, for most modules we
> >>>> aren't even descending into "parameter" level checks today: most
> >>>> modules are only enforcing at class level.
> >>>>
> >>>> Honestly it is still probably the wrong tool for this, as the issue
> >>>> really isn't javadocs related. But the doclet is a hammer we can use
> >>>> for checks like this.
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >>>> For additional commands, e-mail: dev-help@lucene.apache.org
> >>>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Lucene 9.2 release [ In reply to ]
Thanks Robert for elaborating. In that case (older Java11 is the cause), it
makes sense to me that CI builds didn't hit it.

> I'm also ok with failing hard on the build if someone tries to use
> such old stuff.

I'd agree with this and it'd be great if we can fail to build locally and
encourage devs to use a newer patch version of Java (instead of blaming
developers for not upgrading jdk they use) - I have no good idea at all
though.

Tomoko


2022?5?18?(?) 13:04 Robert Muir <rcmuir@gmail.com>:

> I'm unable to even download an old enough jdk version to reproduce the
> javadocs bugs Alan hits. The oldest you can get from adoptopenjdk
> archives are 4-year old java 11 versions, still not old enough.
>
> There's no value to testing such broken old versions (e.g. 11.0.1) in
> our CI when we've already done exactly that, years ago, and reported
> bugs back and iterated. ppl should use most recent versions (e.g.
> 11.0.15), especially for smoketesting and development. It is expected
> that tests may fail, build may fail, you might hit SIGSEGV from
> compiler, etc, if you use old buggy java 11.0.1 or similar.
> I'm also ok with failing hard on the build if someone tries to use
> such old stuff.
>
> On Tue, May 17, 2022 at 11:39 PM Robert Muir <rcmuir@gmail.com> wrote:
> >
> > But that's not the case at all. I suspect it is simply that Alan used
> > an older version of java 11, one that has a javadocs bug.
> >
> > On Tue, May 17, 2022 at 11:26 PM Tomoko Uchida
> > <tomoko.uchida.1111@gmail.com> wrote:
> > >
> > > > I think the issue will boil down to exact version of java 11. It has
> to be the one with the javadocs bug that emits broken links in this
> situation.
> > >
> > > Yes - I think it'd be great if we can detect bugs in our code and the
> language itself we depend on (Java 11) on nightly CI builds, not on the
> release process (if possible!) :)
> > >
> > > Tomoko
> > >
> > >
> > > 2022?5?18?(?) 9:46 Robert Muir <rcmuir@gmail.com>:
> > >>
> > >> I think the issue will boil down to exact version of java 11. It has
> to be the one with the javadocs bug that emits broken links in this
> situation.
> > >>
> > >> On Tue, May 17, 2022, 8:39 PM Tomoko Uchida <
> tomoko.uchida.1111@gmail.com> wrote:
> > >>>
> > >>> > I’ve started the release process using the wizard, which has found
> some broken links in javadoc.
> > >>>
> > >>> I'm just interested in this point - as Uwe pointed out, Jenkins
> servers (and also GitHub Actions I think) should hit the problem as they
> run on branch_9x and Java 11 on a regular basis.
> > >>> Could you let me know the exact command or the corresponding wizard
> lines? If there are gaps between the nightly build and the wizard, we could
> try to fill the gap.
> > >>>
> > >>> Tomoko
> > >>>
> > >>>
> > >>> 2022?5?17?(?) 21:54 Robert Muir <rcmuir@gmail.com>:
> > >>>>
> > >>>> On Tue, May 17, 2022 at 5:59 AM Alan Woodward <romseygeek@gmail.com>
> wrote:
> > >>>> >
> > >>>> > It was part of the release process, which runs with Java 11. It
> should be fixed now.
> > >>>> >
> > >>>> > > Newer java versions won't make a broken link, you just won't
> have a link at all.
> > >>>> >
> > >>>> > This seems a bit of a shame, as some of the problems were genuine
> API bugs - public methods with package-private parameter classes, and so
> on. Do we have other ways of detecting these? Warning levels on the
> compiler maybe?
> > >>>> >
> > >>>>
> > >>>> Agreed, although we are really abusing the functionality. Main
> purpose
> > >>>> of the check is to prevent broken links (HTTP 404 from the website,
> > >>>> etc).
> > >>>>
> > >>>> I don't know of a built-in way to do the exact check. One idea is to
> > >>>> add a check to our custom doclet:
> > >>>>
> https://github.com/apache/lucene/blob/main/dev-tools/missing-doclet/src/main/java/org/apache/lucene/missingdoclet/MissingDoclet.java
> > >>>>
> > >>>> Element has getModifiers() which should be enough to check the
> > >>>> visibility of things like parameters and return type. However, we
> > >>>> might have to restructure the checker a bit, for most modules we
> > >>>> aren't even descending into "parameter" level checks today: most
> > >>>> modules are only enforcing at class level.
> > >>>>
> > >>>> Honestly it is still probably the wrong tool for this, as the issue
> > >>>> really isn't javadocs related. But the doclet is a hammer we can use
> > >>>> for checks like this.
> > >>>>
> > >>>>
> ---------------------------------------------------------------------
> > >>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > >>>> For additional commands, e-mail: dev-help@lucene.apache.org
> > >>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: Lucene 9.2 release [ In reply to ]
> I'd agree with this and it'd be great if we can fail to build locally and encourage devs to use a newer patch version of Java (instead of blaming developers for not upgrading jdk they use) - I have no good idea at all though.

This should be simple. In alternative-jdk-support.gradle, check
whether jvmCurrent's JvmInstallationMetadata is on JDK 11 major and if
so, verify the minor to be at least at a certain bugfix release? You
can parse out the minor version using Runtime.Version API [1] from one
of these (not sure which one gradle extracts):

String getImplementationVersion();
String getRuntimeVersion();
String getJvmVersion();

https://docs.oracle.com/javase/9/docs/api/java/lang/Runtime.Version.html

D.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Lucene 9.2 release [ In reply to ]
Thanks, Dawid for the pointer.
If there is a distribution-agnostic and reliable minor/patch version, we
could specify a more detailed minimum requirement version for building.
I think we shouldn't limit the distribution - or, we should (at least on
making the release artifact)?

Tomoko


2022?5?18?(?) 15:12 Dawid Weiss <dawid.weiss@gmail.com>:

> > I'd agree with this and it'd be great if we can fail to build locally
> and encourage devs to use a newer patch version of Java (instead of blaming
> developers for not upgrading jdk they use) - I have no good idea at all
> though.
>
> This should be simple. In alternative-jdk-support.gradle, check
> whether jvmCurrent's JvmInstallationMetadata is on JDK 11 major and if
> so, verify the minor to be at least at a certain bugfix release? You
> can parse out the minor version using Runtime.Version API [1] from one
> of these (not sure which one gradle extracts):
>
> String getImplementationVersion();
> String getRuntimeVersion();
> String getJvmVersion();
>
> https://docs.oracle.com/javase/9/docs/api/java/lang/Runtime.Version.html
>
> D.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: Lucene 9.2 release [ In reply to ]
I think it makes sense to fail the build in both cases. An early
warning to upgrade buggy old java releases...

D.

On Wed, May 18, 2022 at 9:06 AM Tomoko Uchida
<tomoko.uchida.1111@gmail.com> wrote:
>
> Thanks, Dawid for the pointer.
> If there is a distribution-agnostic and reliable minor/patch version, we could specify a more detailed minimum requirement version for building.
> I think we shouldn't limit the distribution - or, we should (at least on making the release artifact)?
>
> Tomoko
>
>
> 2022?5?18?(?) 15:12 Dawid Weiss <dawid.weiss@gmail.com>:
>>
>> > I'd agree with this and it'd be great if we can fail to build locally and encourage devs to use a newer patch version of Java (instead of blaming developers for not upgrading jdk they use) - I have no good idea at all though.
>>
>> This should be simple. In alternative-jdk-support.gradle, check
>> whether jvmCurrent's JvmInstallationMetadata is on JDK 11 major and if
>> so, verify the minor to be at least at a certain bugfix release? You
>> can parse out the minor version using Runtime.Version API [1] from one
>> of these (not sure which one gradle extracts):
>>
>> String getImplementationVersion();
>> String getRuntimeVersion();
>> String getJvmVersion();
>>
>> https://docs.oracle.com/javase/9/docs/api/java/lang/Runtime.Version.html
>>
>> D.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Lucene 9.2 release [ In reply to ]
I'll take a look if I have a chance.
I'd like to draw attention to my second question while we are still here...
should we limit the OpenJDK distribution (for building)? My worry here is,
that minor versions could depend on the distributor.



2022?5?18?(?) 16:10 Dawid Weiss <dawid.weiss@gmail.com>:

> I think it makes sense to fail the build in both cases. An early
> warning to upgrade buggy old java releases...
>
> D.
>
> On Wed, May 18, 2022 at 9:06 AM Tomoko Uchida
> <tomoko.uchida.1111@gmail.com> wrote:
> >
> > Thanks, Dawid for the pointer.
> > If there is a distribution-agnostic and reliable minor/patch version, we
> could specify a more detailed minimum requirement version for building.
> > I think we shouldn't limit the distribution - or, we should (at least on
> making the release artifact)?
> >
> > Tomoko
> >
> >
> > 2022?5?18?(?) 15:12 Dawid Weiss <dawid.weiss@gmail.com>:
> >>
> >> > I'd agree with this and it'd be great if we can fail to build locally
> and encourage devs to use a newer patch version of Java (instead of blaming
> developers for not upgrading jdk they use) - I have no good idea at all
> though.
> >>
> >> This should be simple. In alternative-jdk-support.gradle, check
> >> whether jvmCurrent's JvmInstallationMetadata is on JDK 11 major and if
> >> so, verify the minor to be at least at a certain bugfix release? You
> >> can parse out the minor version using Runtime.Version API [1] from one
> >> of these (not sure which one gradle extracts):
> >>
> >> String getImplementationVersion();
> >> String getRuntimeVersion();
> >> String getJvmVersion();
> >>
> >>
> https://docs.oracle.com/javase/9/docs/api/java/lang/Runtime.Version.html
> >>
> >> D.
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >> For additional commands, e-mail: dev-help@lucene.apache.org
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: Lucene 9.2 release [ In reply to ]
> I'd like to draw attention to my second question while we are still here... should we limit the OpenJDK distribution (for building)? My worry here is, that minor versions could depend on the distributor.

This is a valid concern but it'd take some trial and error to verify
which version numbers are used by packaging openjdk for various
releases. Realistically, the JDK part (standard library) is nearly the
same in all/ most of them? The least that could be done is to apply
the restriction to just a particular vendor/ release and emit a
warning for unrecognized ones.

Dawid

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

1 2  View All