Thanks Sebb! Gary
On Thu, Dec 10, 2015 at 3:24 AM, sebb <seb...@gmail.com> wrote: > I have now moved the files to > > http://svn.apache.org/repos/asf/commons/cms-site/trunk/doap/ > > and updated the script that processes them [1] accordingly and > recreated the properties [2] file. > > There may still be some DOAP files lying around in branches; I will > try to remove these gradually, merging any relevant content. > Obviously any DOAP files in tags will have to remain. > > [1] > http://svn.apache.org/repos/asf/commons/cms-site/trunk/conf/parse-latest-release.py > [2] > http://svn.apache.org/repos/asf/commons/cms-site/trunk/conf/component_releases.properties > > > On 27 November 2015 at 20:12, Phil Steitz <phil.ste...@gmail.com> wrote: > > On 11/27/15 3:26 AM, sebb wrote: > >> Compress recently moved to Git, so the URL for its DOAP changed. > >> > >> I originally suggested that all the Commons DOAPs could be stored in a > >> common SVN location, but that idea met with resistance as several > >> people felt it was better kept with the source code. > >> > >> Since then, the release summary file [1] has been introduced. > > > > That file is just used to generate the data in the latest version / > > release date columns on the main commons page, right? I would be +1 > > for dropping that file and those columns. The components are all > > linked and you can get release info from the component pages. Just > > one less thing to worry about when cutting releases. IIUC what you > > say below, this may be moot though. > >> > >> It might be sensible to move the DOAPs there too? > >> That would allow the script to automatically extract the latest > releases. > >> At present it assumes all the DOAPs are in SVN, which is no longer the > case. > >> > >> == > >> > >> The disadvantage of storing DOAPs in the source tree is that the DOAP > >> is not intended for release, and so is not included in the archives. > >> However it is included in tags and branches by default. This causes a > >> discrepancy when comparing the tag with the source archive. Also if > >> there are branches, care must be taken to ensure that the correct DOAP > >> is maintained (it's not unknown for a branch to take over from trunk - > >> or indeed for both to be used for releases). > > > > Makes sense to me. So +1 to "rope-the-doaps" somewhere :) Would be > > great if the reporter thingy or something else could be used to > > auto-update them on release. That would make *2* less things to do > > for RMs. Yay! > > > > Phil > >> > >> [1] > http://svn.apache.org/repos/asf/commons/cms-site/trunk/conf/component_releases.properties > >> > >> --------------------------------------------------------------------- > >> 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 > > > > --------------------------------------------------------------------- > 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
