kinow commented on issue #1293: URL: https://github.com/apache/jena/issues/1293#issuecomment-1374143735
Not sure if CWLViewer is using Jena 4 and 3 at the same time. Or if it's using Taverna for the research objects files, and Jena4 graphs for the CWL workflow (I **hope** that's what it's doing). I've created an issue to sort out these two versions of Jena in the CWL Viewer later (it has other things in the pipeline, Spring Data 3 upgrade, newer versions of hibernate/postgres, migration of servers, etc). @afs coming back to changelog in Jena; >>Could be nice to move the CHANGELOG in the code itself so that it's not necessary to be registered on the mailing list to easily get it. It could also be retrieved by tools like RenovateBot or similar that automatically suggest dependencies upgrade. > >What other tools are there? >Specifically, what does github use to populate the dependabot PR with change information? As far as I know, it parses the changelog from files in the source code repo. I knew it used `CHANGELOG`. I looked at their docs but it was not clear, so had a look at their source code. This is the list of files they appear to accept: - [`changelog news changes history release whatsnew releases`](https://github.com/dependabot/dependabot-core/blob/0603ec94756a975b2ea928acf7a74213198599be/common/lib/dependabot/metadata_finders/base/changelog_finder.rb#L17-L20) (the extension doesn't seem to matter) In each of those files, it uses a "pruner" to locate the desired version: https://github.com/dependabot/dependabot-core/blob/0603ec94756a975b2ea928acf7a74213198599be/common/lib/dependabot/metadata_finders/base/changelog_finder.rb#L124 That's what I could understand. So I think having a `CHANGELOG.md` file in the root of the Jena repository, neighbor to README and LICENSE, would include our changelog in dependabot. For non-dependabot users, I think most people are familiar with, and look for these files. On how to generate these files; I think we could try to automate it if it's really hard to keep track of the changes, maybe extract it from Git and/or JIRA. But I think it could be simpler to decide what to include when merging pull requests. We could update our pull request template to include a line like: - `CHANGES.md` entry included if this is a change that can affect users To remind us whether we should include something in the changelog. This way, `main` would always have the snapshot changelog, and during the release we would have to remember to update the changelog entry (date/version). And after the release start a new changelog for the next version… Not sure if that would complicate much the release process. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
