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
