Congratulations and welcome, Michael!
Tomoko
2021年10月13日(水) 1:44 Joel Bernstein :
>
> Welcome, Michael!
>
> Joel Bernstein
> http://joelsolr.blogspot.com/
>
>
> On Sun, Oct 10, 2021 at 2:41 AM Atri Sharma wrote:
>>
>> Welcome, Michael!
>>
>> On Thu, 7 Oct 2021, 23:29 Michael Sokolov, wrote:
Please vote for release candidate 1 for Lucene/Solr 8.10.1
The artifacts can be downloaded from:
https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.10.1-RC1-rev2f24e6a49d48a032df1f12e146612f59141727a9
You can run the smoke tester directly with this command:
python3 -u
If a dedicated issue for the stand-alone luke distribution is needed,
I think this is the one: LUCENE-9978. I have not worked on this yet,
since I thought it would be better to wait until the upcoming release
is completed.
I'm ready to start working on this, but it could/should be delegated
to
Hi Praveen,
Have you seen this page on the wiki?
https://cwiki.apache.org/confluence/display/LUCENE/DeveloperTips#DeveloperTips-TipstoconfigureIDEs
By running `gradlew tasks`, you should see a section about IDE tasks that
help with importing the project in Eclipse. For me running tests then
Thank you for the discussion. I think it'll be easier to take this
forward if presented with a concrete example of what a "binary"
release can look like, what Luke distribution is, etc.
Let's start by completing the updates to how artifacts are assembled
and making the smoke tester work with
I remember the issue and linked to it, Tomoko. Luke distribution
should be done as part of the binary artifacts refactoring - these are
connected issues, I think.
Dawid
On Tue, Oct 12, 2021 at 10:07 AM Tomoko Uchida
wrote:
>
> If a dedicated issue for the stand-alone luke distribution is
Hi,
I full agree with most of the things here. Now that Solr is no longer part of
Lucene, I also see no reason to have all dependencies and JAR artifacts in a
TAR file!
On the other hand, binary artifacts makes reviewing the artifacts easier during
a release. I am one of the persons that not
I'm fine with just Lucene binaries, signed JARs and checksums +
pre-rendered documentation for convenience purposes.
> Without a binary release it's also harder to do a quick test with the JAR
> files, because they are not yet on Maven Central,
You can install the artifacts locally (~/.m2 -
> Why I am telling this: I'd like to test the "official" to-be-released JAR
> files with their hashes as seen and uploaded to ASF servers, so mavenLocal is
> not my first preference.
Correct - the same build (from the same git revision) will not result
in identical JARs. This can be done but
> In short: A targz file is just easier to "manually" review.
This is off-topic: I'm curious about if some part of the manual review
can be done at daily automated routines (tests, precommit checks,
etc.). I'm not against having a binary distribution for pre-release
review or other purposes (as
Hi,
> I'm fine with just Lucene binaries, signed JARs and checksums +
> pre-rendered documentation for convenience purposes.
Sure, thanks.
> > Without a binary release it's also harder to do a quick test with the JAR
> > files,
> because they are not yet on Maven Central,
>
> You can install
Welcome, Michael!
Joel Bernstein
http://joelsolr.blogspot.com/
On Sun, Oct 10, 2021 at 2:41 AM Atri Sharma wrote:
> Welcome, Michael!
>
> On Thu, 7 Oct 2021, 23:29 Michael Sokolov, wrote:
>
>> Welcome, Michael!
>>
>> On Wed, Oct 6, 2021 at 9:34 AM Dawid Weiss wrote:
>> >
>> > Hello
12 matches
Mail list logo