On 16 April 2016 at 01:00, James Carman <ja...@carmanconsulting.com> wrote: > That definitely seems easier. +1.
Another advantage is that it should make it simpler to automate creating the dist/dev staging area from Nexus. The staging area could be created as dist/dev/commons/abc/abc-123-RC4. There would then be less chance of voting on stale artifacts as each RC would have its own area. > Would that mess up any sort of sync jobs > (maven and stuff)? AFAIK Maven does not know the existing layout, since it varies between projects. (The commons build plugin is the only place that does know, and it has to be specifically told) Mirrors will take everything under dist, including dist/commons I suppose it's possible some 3rd parties may make assumptions about the layout, but it's not standard across ASF projects. > On Fri, Apr 15, 2016 at 7:26 PM Gary Gregory <garydgreg...@gmail.com> wrote: > >> I am OK with anything that makes releasing easier. >> >> Gary >> >> On Fri, Apr 15, 2016 at 4:02 PM, 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 >> > >> > >> >> >> -- >> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >> Java Persistence with Hibernate, Second Edition >> <http://www.manning.com/bauer3/> >> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >> Spring Batch in Action <http://www.manning.com/templier/> >> Blog: http://garygregory.wordpress.com >> Home: http://garygregory.com/ >> Tweet! http://twitter.com/GaryGregory >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
