+1 for the change for future releases. Being able to do svn mv (or rm) on a single folder simplifies releasing and reduces chance of errors.
Is the -src and -bin endings already used across all of Commons? That would be a bit more important without source/ and binaries/ (Do some have download artifacts beyond bin and src?) I think it is important to mention this URL pattern change in release notes for downstream distributors, e.g. Debian recipies that download https://archive.apache.org/commons/foo/source/foo-${version}-src.tar.gz (They have to use archive as older versions disappear from official mirrors) On 16 Apr 2016 00:02, "sebb" <seb...@gmail.com> wrote: > The dist layout currently splits archives into source/ and binaries/. > Where there are multiple active versions, these are all in the same > directory. > > IMO this layout is not ideal any more. > > It is harder to tidy up old releases (files have to be individually > deleted) > It is harder to move files from dist/dev to dist/release > > Are there any disadvantages to allowing the layout to change? > > Unless there are objections, I propose to update the commons build > plugin to support download pages using version ids, e.g. instead of > the present layout: > > lang/source/commons-lang-2.6-src.* > lang/source/commons-lang3-3.4-src.* > lang/binaries/commons-lang-2.6-bin.* > lang/binaries/commons-lang3-3.4-bin.* > > It would look like: > > lang/commons-lang-2.6/commons-lang-2.6-[bin|src].* > lang/commons-lang3-3.4/commons-lang3-3.4-[bin|src].* > > > Note: I don't think we should move the existing releases > > The intention is to allow new releases to optionally migrate to the new > layout. > This would be done on the basis of a new property, e.g. > commons.release.layout=version > If the property is defined, then the new layout is used; if not, then > the current source/binaries layout is used. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
