On Wed, 16 Mar 2022 at 22:26, Gilles Sadowski <gillese...@gmail.com> wrote:
>
> Le mer. 16 mars 2022 à 19:00, Mark Thomas <ma...@apache.org> a écrit :
> >
> > On 16/03/2022 17:53, sebb wrote:
> > > As the subject says.
> > >
> > > We currently use separate directories for binaries and source, each of
> > > which may contain multiple versions.
> > >
> > > This is a bit awkward to maintain compared with a directory per
> > > release which would contain both binaries and source.
> > >
> > > I think we should consider moving to individual release directories.
> > >
> > > This would mean changes to various scripts etc, so would not be trivial.
> > >
> > > If we do decide to do so, it would make sense to try this on a
> > > component that normally only has one current version on release.
> > >
> > > WDYT?
> >
> > I like the idea in general. It makes managing releases a little easier.
> >
> > However, there would be an impact is on users that have scripted
> > downloads. The change in the location will require changes to all of
> > those scripts. Does the benefit (primarily for us) justify the cost of
> > those changes (primarily for users)? This might be something to thing
> > about when we have a new major version.
>
> What about
>  * changing the location if it makes things simpler for us, and
>  * writing a script that generates the old layout (symbolic links)
>    to keep things simple for users.
> ?

That might work, but I think redirects might be better than symbolic links.
Hopefully they could be defined in a single file, rather than
scattered around the subdirectories.
This would make them much easier to maintain.

I'll try some experiments.


> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to