Please use change log or github releases #844
Comments
|
It was originally removed because it's not helpful, it's redundant with the git history, and it frequently drifts out of date. If somebody wants to see the CHANGELOG, they can look at the git history between the tags. That's all this generated process is doing. I don't see value in merely copying information that's already readily available by another means. The reason for removing it is still valid here. Nothing has changed. Therefore, I am inclined to remove it again. As for GitHub releases, I don't mind using them, but unless they contain something new, it just seems like more work that doesn't really add any value. You can already download a tarball from a tag, so unless the body of the release description actually contains new information (not merely a CHANGELOG that can be readily viewed elsewhere), then I don't see the point. On the other hand, I think there are things we should be doing for releases that actually do add value... like making sure the tags are GPG-signed. |
|
If we use releases, which most repos do and only discuss high level changes not everything that changed, I think that would go a long way to helping users. I find myself always looking there first and typically a change log might be referenced. But many times as well that is entirely automated. Maven does it, mockito does it, others do as well. It provides automated way to quickly look and if we find we need to add more we can. That is 100% better than change log as it is per release rather than all releases. My main concern here is trying to understand what is waht and milestones mean nothing and are not front and center. Also tools like dependabot, renovate, synk, and others use releases for their data with fall back to CHANGELOG.md |
|
If you want to do releases, that's fine with me. I just don't want the autogenerated stuff. We can link to the milestone on the release page, or to the full history since the last release. For example: |
* Update maven build to use revelc prefixed property name for formatting profiles in the parent POM * Drop the sonatype deploy snapshot configuration (not needed and not safe to use personal individual credentials on a shared repository this way - personal secrets still need to be deleted from the GitHub repository); discussed on revelc#889 * Re-drop autogenerated CHANGELOG file and related README in favor of adding a link to the milestone or full changeset in the GitHub release notes; discussion on revelc#844 * Bump snapshot version to 2.25.0 and update the compatible Eclipse version in the site documentation * Add missing scm section (revelc/revelc#12) * Drop site-specific distributionManagement section and related scmpublish plugin settings (those can be run manually entirely from the command-line with command-line parameters, if needed, but it shouldn't be necessary if the GitHub plugin defined in the site-deploy phase of the site lifecyle is used, as defined in the parent POM); discussed on revelc#905 * Revert to using stable versions of maven site plugin and Fluido skin, defined in the parent POM, rather than override here (when these get stable releases, the parent POM can be updated, and then the site descriptor will need to be updated, but for now, these can use the latest stable versions) * Add dependencyConvergence rule to the build, and exclude conflicting transitive dependencies, in order to affix them to specific versions (some of this might not be needed once some of the other plugins start doing dependency convergence also, like xml-formatter and jsdt-core) * Make sure slf4j-api is marked as provided (address concerns from revelc#846) It would be easier if we could converge on what maven-core or maven-plugin-api uses, but those dependencies are opaque to us, so we just have to assume it's provided and compatible with what we're using; slf4j has a high degree of compatibility, though, so this shouldn't be much of a concern * Drop plexus-xml dependency (we don't use it, and the one that comes with plexus-resources is fine with Maven 3); see comment on revelc#851
* Update maven build to use revelc prefixed property name for formatting profiles in the parent POM * Drop the sonatype deploy snapshot configuration (not needed and not safe to use personal individual credentials on a shared repository this way - personal secrets still need to be deleted from the GitHub repository); discussed on #889 * Re-drop autogenerated CHANGELOG file and related README in favor of adding a link to the milestone or full changeset in the GitHub release notes; discussion on #844 * Bump snapshot version to 2.25.0 and update the compatible Eclipse version in the site documentation * Add missing scm section (revelc/revelc#12) * Drop site-specific distributionManagement section and related scmpublish plugin settings (those can be run manually entirely from the command-line with command-line parameters, if needed, but it shouldn't be necessary if the GitHub plugin defined in the site-deploy phase of the site lifecyle is used, as defined in the parent POM); discussed on #905 * Revert to using stable versions of maven site plugin and Fluido skin, defined in the parent POM, rather than override here (when these get stable releases, the parent POM can be updated, and then the site descriptor will need to be updated, but for now, these can use the latest stable versions) * Add dependencyConvergence rule to the build, and exclude conflicting transitive dependencies, in order to affix them to specific versions (some of this might not be needed once some of the other plugins start doing dependency convergence also, like xml-formatter and jsdt-core) * Make sure slf4j-api is marked as provided (address concerns from #846) It would be easier if we could converge on what maven-core or maven-plugin-api uses, but those dependencies are opaque to us, so we just have to assume it's provided and compatible with what we're using; slf4j has a high degree of compatibility, though, so this shouldn't be much of a concern * Drop plexus-xml dependency (we don't use it, and the one that comes with plexus-resources is fine with Maven 3); see comment on #851 * Upload build logs on GitHub Actions failure Try to make the build windows-friendly * Treat test files as binaries, so git won't mangle the line endings * Make sortpom-maven-plugin ignore line endings when verifying * Commit correct CRLF line endings for AnyClassCRLF.java and someFile.xml
Neither are being used. We did have a changelog but was deleted because manually created.
If changelog are to be restored, we just need to add this into the parent root for releases and it will coverall all repos.
The parent is using that and I've tested it. It works rather well for just a file replacement.
Otherwise, we should automate releases off the tags which use the milestones.
Without either of those the bots - dependabot included, will not show anything as being updated per the release. They use CHANGELOG.md or github releases for that.
At the moment, I think doing this with mavanagaiata would be easiest since that seems to have been introduced recently so already feasible solution.
The text was updated successfully, but these errors were encountered: