> 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 it
> 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 you
t;
> > So I am not fully happy to completely throw away binary artifacts.
> > Uwe
> >
> > -
> > Uwe Schindler
> > Achterdiek 19, D-28357 Bremen
> > https://www.thetaphi.de
> > eMail: u...@thetaphi.de
> >
> > > -Original Message-
>
gt; -Original Message-
> > From: Robert Muir
> > Sent: Tuesday, October 12, 2021 2:27 AM
> > To: dev@lucene.apache.org
> > Subject: Re: Simplify the release artifacts
> >
> > Well there's definitely a good reason to stop publishing convenience
>
day, October 12, 2021 2:27 AM
> To: dev@lucene.apache.org
> Subject: Re: Simplify the release artifacts
>
> Well there's definitely a good reason to stop publishing convenience
> binaries: they aren't required.
>
> Lucene is a library.
>
> I think it ma
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 needed,
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 anot
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 these
Well there's definitely a good reason to stop publishing convenience
binaries: they aren't required.
Lucene is a library.
I think it makes sense to publish convenience binaries for the luke
App, that's it.
Otherwise, we should publish just source code, that's all that is required.
Library users
+1 to all suggestions.
ASF has a release policy
(https://www.apache.org/legal/release-policy.html#release-distribution) and
artifacts must be uploaded to the mirrors.
There is also a release distribution policy
(https://infra.apache.org/release-distribution.html#download-links) that says
"
For what it's worth, I did a little survey on how other
library/sdk/framework projects distribute their artifacts other than
Maven repositories.
- Log4j distributes tgz and zip artifacts via the "Download" page.
https://logging.apache.org/log4j/2.x/download.html
- JavaFX distributes only zip arti
+1 overall, comments inline.
On Mon, Oct 11, 2021 at 7:48 AM Dawid Weiss wrote:
>
> Hi.
>
> These are the thoughts that occurred to me while rewriting the
> packaging in the build system. I think they're worth the discussion
> because they could limit the size of the published artifacts as well
>
12 matches
Mail list logo
