commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Re: [ALL] Move DOAP files to unchanging URL?
Date Thu, 10 Dec 2015 11:24:40 GMT
I have now moved the files to

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.


On 27 November 2015 at 20:12, Phil Steitz <> 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]
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message