On 25 April 2016 at 10:13, Stian Soiland-Reyes <st...@apache.org> wrote: > On 21 April 2016 at 12:06, sebb <seb...@gmail.com> wrote: > >> Note that once we have released (say) NET 3.5, the downloads for NET >> 3.4 need to be removed from the mirrors. >> So the only place that the links will then exist is in the archives. >> >> Unless we also set up links for every past release in every Commons >> component, there is going to be a discontinuity at some point in the >> naming convention. >> >> Seems to me we either accept that we cannot change the names ever, or >> we accept that downstream users will need to change their URLs. >> >> They have to change the URL anyway when a new release is made. >> Does it really matter if the URL changes more than just a version string? > > Yes,
I don't understand why that should be. Can you explain in more detail? > so I initially suggested a simpler approach, we only do the new > layout for new releases - as they would come with an equivalent > release email etc - however Gilles suggested we do the change for all > components at once - which I admit gives greater consistency but could > also break many downstream packaging in one go unless we do > consistency symlinks **for the transitionary versions**. (On the > other side that would be a "everything breaks at once" event rather > than "every component download script breaks bit by bit over the next > years) Nor do I understand how it helps to have transition links unless *every* release has a link. Unless we continue providing links for every future release, the downstream provider has to change the download URL. Once they have done that, why should there be a need to refer to previous releases at all? And if there is a need to do so, does it really matter if the URL is different? In any case where components change packages the artifact name will change; I don't see how this is any different. > > > > -- > Stian Soiland-Reyes > Apache Taverna (incubating), Apache Commons RDF (incubating) > http://orcid.org/0000-0001-9842-9718 > > --------------------------------------------------------------------- > 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
