[
https://issues.apache.org/jira/browse/LUCENE-6258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14327820#comment-14327820
]
Hoss Man commented on LUCENE-6258:
----------------------------------
a) worth looking at the build.xml files to make sure we understand what is
currently diff between the two -- off the top of my head i seem to recall line
endings on shell scripts being diff (to play nicer with cygwin when windows
users use zip files) ... on the flip side: tgz lets us preserve executable bits
on shell scripts in a way i don't believe works consistently in zip files? ...
point is: that should be reviewed thoroughly before ripping out one or the
other.
b) this sounds like a made up problem to me -- end users are only helped by
having multiple formats, not harmed. users aren't downloading both the tgz and
zip file releases -- they are picking one and using that. the only size
decrease here is in what we as developers have to download to test when voting
on an RC.
> Cut binary releases down to a single format
> -------------------------------------------
>
> Key: LUCENE-6258
> URL: https://issues.apache.org/jira/browse/LUCENE-6258
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Ryan Ernst
>
> In LUCENE-6247, one idea discussed to decrease the size of release artifacts
> was removing either tgz or zip from our binary releases.
> The source releases are already only in tgz. I think we should do the same
> for binary releases. I looked at a number of other Apache projects, and the
> results are mixed, but there definitely are many major projects (hadoop,
> couchdb, cassandra, cordova) that only release tgz. Anyone who can deal with
> running using Lucene or Solr should have the skills necessary to extract an
> archive in either format, so in this way I think either format is fine, but I
> think matching what we release source in has a nice look.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]