commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: [ALL] Move DOAP files to unchanging URL?
Date Fri, 11 Dec 2015 08:05:58 GMT
Thanks Sebb!

Gary

On Thu, Dec 10, 2015 at 3:24 AM, sebb <sebbaz@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.steitz@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-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


-- 
E-Mail: garydgregory@gmail.com | ggregory@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message