Rethink current CHANGELOG as Release Notes

[tdruez]

The changelog can be automatically generated from the commits at release time.

What would be more interesting instead of maintaining the current changelog at https://github.com/nexB/scancode.io/blob/main/CHANGELOG.rst would be to provide "Release notes" including pertinent information about new features, new pipelines, deprecation, etc... Similar to Django's release notes https://docs.djangoproject.com/en/5.0/releases/5.0/

[swastkk]

Hey @tdruez I was thinking to work on this, the possible procedure would be

1. Writing a Script for categorising the type of commit and addition of that detailed commit in the CHANGELOG.rst using the
2. Adding the Script to run in the workflow file and automated Addition to the CHANGELOG.rst just like that in the https://github.com/nexB/scancode.io/releases
3. After the PR is merged, detailed commit message will be in CHANGELOG explaining the CHanges made in the Codebase.

And that's it.

[tdruez]

And that's it.

Not exactly, my point is to have detailed notes along a release about what's new and what requires special attention for upgrading. Similar to https://docs.djangoproject.com/en/5.0/releases/5.0/

[swastkk]

And that's it.

Not exactly, my point is to have detailed notes along a release about what's new and what requires special attention for upgrading. Similar to https://docs.djangoproject.com/en/5.0/releases/5.0/

So that CHANGELOG would be hard coded since you are mentioning in https://docs.djangoproject.com/en/5.0/releases/5.0/ instead of that automatically generated from the PR's squashed commit having detailed description of the changes made in the codebase and automatically added in the CHANGELOG?

[tdruez]

My suggestion:

• The current CHANGELOG.rst evolve into "Release notes" that will look somehow similar to https://docs.djangoproject.com/en/5.0/releases/5.0/
• The changelog content is generated at release time using the "Generate release notes" features in GitHub: "Select a valid tag to automatically add the Markdown for all the merged pull requests from this diff and contributors of this release"

[swastkk]

I have a idea to automate this process like instead of having CHANGELOG , we should also go with the approach that the https://github.com/django/django/ has used of having https://github.com/django/django/tree/main/docs/releases with each file created on the new release with all this using a GitHub Action The GitHub Action will work at the time of release, take up the Target of the change branch, Tag of the version details and getting the commit details on that branch and then adding in the form of the release file or changes in the CHANGELOG.

[tdruez]

The content in https://github.com/django/django/tree/main/docs/releases seems to be manually added though.

[swastkk]

The content in https://github.com/django/django/tree/main/docs/releases seems to be manually added though.

But we can came up with something automated stuff, lemme try this on a empty repo of myself and if works i will implement over scancode.io whatsay?

[tdruez]

@swastkk I think you are missing my initial point:

The changelog can be automatically generated from the commits at release time. What would be more interesting instead of maintaining the current changelog at would be to provide "Release notes" including pertinent information about new features, new pipelines, deprecation, etc...

[swastkk]

Ya I understood that thing, you are saying like we use to maintain the ChangeLog on time to time basis but this changelog is easily generated at release time, so we have to develop a method to get the Changelog file updated on the release time or alternatively creating a New release file with version.md containing all the information about the changelog on version release.

[swastkk]

For Example

v33.1.0

• Rename multiple pipelines for consistency and precision:
  • docker: analyze_docker_image
  • root_filesystems: analyze_root_filesystem_or_vm_image
  • docker_windows: analyze_windows_docker_image
  • inspect_manifest: inspect_packages
  • deploy_to_develop: map_deploy_to_develop
  • scan_package: scan_single_package

A data migration is included to facilitate the migration of existing data. Only the new names are available in the web UI but the REST API and CLI are backward compatible with the old names. Issue #1044

• Generate CycloneDX SBOM in 1.5 spec format, migrated from 1.4 previously. The Package vulnerabilities are now included in the CycloneDX SBOM when available. Issue #807
• Improve the inspect_manifest pipeline to accept archives as inputs. Issue #1034
• Add support for "tagging" download URL inputs using the "#" section of URLs. This feature is particularly useful in the map_develop_to_deploy pipeline when download URLs are utilized as inputs. Tags such as "from" and "to" can be specified by adding "#from" or "#to" fragments at the end of the download URLs. Using the CLI, the uploaded files can be tagged using the "filename:tag" syntax while using the --input-file arguments. In the UI, tags can be edited from the Project details view "Inputs" panel. On the REST API, a new upload_file_tag field is available to use along the upload_file. Issue #708

[swastkk]

Implemented both approaches with GitHub action working on the

on:
  release:
    types: [published]

• Having release_notes and then version.md for the release info
• and having the Updated CHANGELOG with each Version release.

but with that on each version release, having detailed information about the changes made in the codebase. Which approch do you think suits the scancode project? For examplary purpose i took the release notes of scancode.io