Subdirectory of the src release

[Houston Putman <ho...@gmail.com>]

Hey everyone,

I'm working on the Slim solr distribution (
https://issues.apache.org/jira/browse/SOLR-16742) and I noticed that the
Solr src release unpacks to a directory without "-src" appended.

E.g. solr-9.2.0-src.tgz will unpack to solr-9.2.0/ instead of
solr-9.2.0-src/

I'm sure this is just how it was done originally, and no one thought to
change it.
Does anyone have historical reasons as to why this is the case?

I'd like to be able to treat all of our release artifacts consistently, so
that they unpack to a folder that matches the name of the distribution.
Are there any objections to changing this starting in 10?
It's not a huge change, but probably something we shouldn't do midway
through 9.
However, if people think we should change sooner rather than later, I'm
fine with that.

- Houston

Re: Subdirectory of the src release

[Ishan Chattopadhyaya <ic...@gmail.com>]

+1 to Alessandro. Thanks Houston

On Tue, 11 Apr, 2023, 9:37 pm Alessandro Benedetti, <a....@sease.io>
wrote:

> +1 in doing it starting in 10, I don't think it's urgent and I like
> consistency!
>
> Cheers
> --------------------------
> *Alessandro Benedetti*
> Director @ Sease Ltd.
> *Apache Lucene/Solr Committer*
> *Apache Solr PMC Member*
>
> e-mail: a.benedetti@sease.io
>
>
> *Sease* - Information Retrieval Applied
> Consulting | Training | Open Source
>
> Website: Sease.io <http://sease.io/>
> LinkedIn <https://linkedin.com/company/sease-ltd> | Twitter
> <https://twitter.com/seaseltd> | Youtube
> <https://www.youtube.com/channel/UCDx86ZKLYNpI3gzMercM7BQ> | Github
> <https://github.com/seaseltd>
>
>
> On Tue, 11 Apr 2023 at 16:46, Houston Putman <ho...@gmail.com>
> wrote:
>
> > Hey everyone,
> >
> > I'm working on the Slim solr distribution (
> > https://issues.apache.org/jira/browse/SOLR-16742) and I noticed that the
> > Solr src release unpacks to a directory without "-src" appended.
> >
> > E.g. solr-9.2.0-src.tgz will unpack to solr-9.2.0/ instead of
> > solr-9.2.0-src/
> >
> > I'm sure this is just how it was done originally, and no one thought to
> > change it.
> > Does anyone have historical reasons as to why this is the case?
> >
> > I'd like to be able to treat all of our release artifacts consistently,
> so
> > that they unpack to a folder that matches the name of the distribution.
> > Are there any objections to changing this starting in 10?
> > It's not a huge change, but probably something we shouldn't do midway
> > through 9.
> > However, if people think we should change sooner rather than later, I'm
> > fine with that.
> >
> > - Houston
> >
>

Re: Subdirectory of the src release

[Alessandro Benedetti <a....@sease.io>]

+1 in doing it starting in 10, I don't think it's urgent and I like
consistency!

Cheers
--------------------------
*Alessandro Benedetti*
Director @ Sease Ltd.
*Apache Lucene/Solr Committer*
*Apache Solr PMC Member*

e-mail: a.benedetti@sease.io


*Sease* - Information Retrieval Applied
Consulting | Training | Open Source

Website: Sease.io <http://sease.io/>
LinkedIn <https://linkedin.com/company/sease-ltd> | Twitter
<https://twitter.com/seaseltd> | Youtube
<https://www.youtube.com/channel/UCDx86ZKLYNpI3gzMercM7BQ> | Github
<https://github.com/seaseltd>


On Tue, 11 Apr 2023 at 16:46, Houston Putman <ho...@gmail.com>
wrote:

> Hey everyone,
>
> I'm working on the Slim solr distribution (
> https://issues.apache.org/jira/browse/SOLR-16742) and I noticed that the
> Solr src release unpacks to a directory without "-src" appended.
>
> E.g. solr-9.2.0-src.tgz will unpack to solr-9.2.0/ instead of
> solr-9.2.0-src/
>
> I'm sure this is just how it was done originally, and no one thought to
> change it.
> Does anyone have historical reasons as to why this is the case?
>
> I'd like to be able to treat all of our release artifacts consistently, so
> that they unpack to a folder that matches the name of the distribution.
> Are there any objections to changing this starting in 10?
> It's not a huge change, but probably something we shouldn't do midway
> through 9.
> However, if people think we should change sooner rather than later, I'm
> fine with that.
>
> - Houston
>