Am 26.06.2015 19:32 schrieb :
> > Am 26.06.2015 19:30 schrieb "Franco Perruna" <francoperrun...@gmail.com>: > > > > Am 26.06.2015 19:01 schrieb "Franco Perruna" <francoperrun...@gmail.com > >: > >> > >> Francoperruna83 > >> > >> Am 26.06.2015 18:52 schrieb "sebb" <seb...@gmail.com>: > >>> > >>> Or just include the URL that triggered the e-mail? > >>> Surely that would give sufficient clue to the project? > >>> > >>> By the way, I received e-mails from the reporter service when I > >>> *deleted* some old release files. > >>> > >>> Surely such mails could/should be suppressed? > >>> > >>> On 26 June 2015 at 09:04, Branko Čibej <br...@apache.org> wrote: > >>> > On 25.06.2015 17:40, Martijn Dashorst wrote: > >>> >> And there is no rule (yet) that there is only one format to rule > them > >>> >> all. A transformation rule specified at project level in the > reporter > >>> >> tool could do the trick as well. > >>> > > >>> > > >>> > Yah ... have each project define a (set of) regular expressions and > use > >>> > the contents of \1. > >>> > > >>> > > >>> > -- Brane > >>> > > >>> > > >>> >> > >>> >> On Thu, Jun 25, 2015 at 5:17 PM, Niclas Hedhman <nic...@hedhman.org> > wrote: > >>> >>> Alex, > >>> >>> I think you made an assumption that "format" meant naming schemes > of > >>> >>> releases, but it didn't. Simple "a defined way" to make that > available for > >>> >>> reporter to pick it up with relative ease. > >>> >>> Your suggestion of a doap-based solution is equally a "format". The > >>> >>> important part, I think, is that "whatever way is chosen", that it > is > >>> >>> documented and notified to PMCs, with optionality to use it. > >>> >>> > >>> >>> For me; DOAP is as good as anything, although there are probably a > great > >>> >>> demand for linking that with Maven publishing "somehow". Since our > Gradle > >>> >>> build is generating all kinds of meta data output anyway, one more > wouldn't > >>> >>> hurt much. > >>> >>> > >>> >>> Cheers > >>> >>> > >>> >>> On Thu, Jun 25, 2015 at 10:31 PM, Alex Harui <aha...@adobe.com> > wrote: > >>> >>> > >>> >>>> > >>> >>>> On 6/25/15, 7:18 AM, "hedh...@gmail.com on behalf of Niclas > Hedhman" > >>> >>>> <hedh...@gmail.com on behalf of nic...@hedhman.org> wrote: > >>> >>>> > >>> >>>>> If the "format" is published, and the "reward" of following it > would be > >>> >>>>> that the reporter picks it up automatically, it could lead to > swift > >>> >>>>> adoption ;-) > >>> >>>> You might get push back about having to change naming schemes. > >>> >>>> > >>> >>>> I’m interested in a list of all current and past releases for my > project. > >>> >>>> I was trying to figure out how to mine archive.a.o or the svn log > for it. > >>> >>>> I’d be willing to maintain an xml file like in DOAP or elsewhere > of not > >>> >>>> just the last, but all releases and links to their downloads with > >>> >>>> “friendly” names for the releases. Then reporter.a.o could grab > from that. > >>> >>>> > >>> >>>> -Alex > >>> >>>> > >>> >>>>> On Thu, Jun 25, 2015 at 9:26 PM, Daniel Gruno < > humbed...@apache.org> > >>> >>>>> wrote: > >>> >>>>> > >>> >>>>>> It has been tried, and it did not work. > >>> >>>>>> People are too inconsistent across projects in how they name > their > >>> >>>>>> release > >>> >>>>>> files, grabbing the version is nigh impossible. > >>> >>>>>> If we had some form of agreement on how to name files, then it > would be > >>> >>>>>> possible. > >>> >>>>>> > >>> >>>>>> With regards, > >>> >>>>>> Daniel. > >>> >>>>>> > >>> >>>>>> > >>> >>>>>> On 2015-06-25 15:11, Martijn Dashorst wrote: > >>> >>>>>> > >>> >>>>>>> Is there a reason why the reporter.a.o can send a message to a > release > >>> >>>>>>> manager that it detected a new release, but is incapable of > >>> >>>>>>> determining a version number and release date? > >>> >>>>>>> > >>> >>>>>>> Martijn > >>> >>>>>>> > >>> >>>>>> > >>> >>>>> > >>> >>>>> -- > >>> >>>>> Niclas Hedhman, Software Developer > >>> >>>>> http://zest.apache.org - New Energy for Java > >>> >>>> > >>> >>> > >>> >>> -- > >>> >>> Niclas Hedhman, Software Developer > >>> >>> http://zest.apache.org - New Energy for Java > >>> >> > >>> >> > >>> > >
