aaronweissler
commented
2 years ago Some considerations:
Should nightly builds get their own release? The alternative could for example be adding nightly assets to the latest full release. I think it would be good for them to have their own release, because it would be easier to see and understand without knowing about the feature beforehand. Potential Problems:
-
How does automatic generation of release notes behave? Unfortunately, the documentation on this is not fully clear, but I suspect that the generation of release notes introduced by #1516 is based on PRs that were merged between the tag of the last release and the tag of the current release. Since every release needs a corresponding tag, creating a nightly release might lead to changenotes only being generated for changes between the latest nightly release and the current actual release. Maybe this issue can be mitigated by deleting the nightly releases and their tags when doing a full release. Otherwise we would have to switch to a different method to generate the release notes.
-
How to not flood the releases page with nightly releases? I personally would say it would be okay to delete any previous nightly release when creating a new one, but it might lead to confusion with users thereof, if a nightly release they were using suddenly doesn't exist anymore or is replaced with another one under the same name but with different contents.
Is your feature request related to a problem? Please describe. When new features have been merged into the master branch, but there is no new release with them yet, you need to build inspectIT Ocelot from source yourself to test the new features.
Describe the solution you'd like Nightly builds that you can use to test new features.