disable the weekly dev build

[FeynmanZhou]

Hi team,

After analyzing the Notation GitHub releases download data, I find the following problems:

• The downloads decreased obviously starting from the first weekly build release
• Each weekly dev build is less than 5 downloads, no users are really using it
• There are too many weekly build releases on the GitHub release page, which confused the new users to choose
• All releases are pre-release, users are hard to find the recommended release from the homepage, people may concern about the pre-release status

According to SemVer, we can convert a pre-release to an official release even if it is still in alpha or v0.x.0. I propose enabling the official release start from Alpha.4 and disabling the weekly dev build now.

[dtzar]

I'm good to move from pre-release to release. However, I'd still like to keep 1 or 2 weekly dev builds and auto-remove the dev builds when a new one comes out.

[FeynmanZhou]

Follow up on this proposal:

1. Notation v0.11.0-Alpha.4 was set to an standard release and can be easily found from the homepage.

2. @dtzar Keeping only 1 latest dev build release sounds good to me. @JeyJeyGao Is this request doable in GH actions?
   But from the latest two releases' download stats (5 and 0 downloads), a less of people were really using the dev build. The release rhythm is also fast due to the beta.1 and rc.1 release will come within around 3 weeks. So I still prefer to disable it temporally.
   

cc @yizha1 @iamsamirzon @vaninrao10 @notaryproject/notation-release-managers

[junczhu]

Hi @FeynmanZhou, you can set a GitHub Action to manage latest dev build release.

GitHub Action Event Trigger including Release

For example, you can run a workflow when a new dev release has been published.

on:
  release:
    types: [published]

According to the GitHub Docs, we can using the GitHub CLI on a runner.

And using GitHub CLI to list releases / delete a release

More Info:

Here is a sample GitHub Action from Marketplace. This action deletes older releases of given repo.
And here is the source code of the GitHub Action above, which is under MIT LICENSE

[JeyJeyGao]

Do we really need weekly dev release now? Can we stop it if no one uses it?

[SteveLasker]

great questions
I don’t think we need lots of weekly releases maintained. We should be having frequent builds, so these are more interim

Building from source sounds far easier than it is if you don’t have the correct environment setup. curl is far easier than make, debug golang versions

Latest 3 is probably fine. Once we have good test coverage, fewer is probably fine.

[dtzar]

• As mentioned: I recommend only keeping the latest weekly dev build, so at any point there is only one dev build available from the last week. This will make it easy to find the actual release.
• The target users are any users or developers who don't want to have to build the binary on their own to test out the latest improvements. The target is also the development team to be able to run that released binary with e2e test suites and also be on the same page with what specific bits are being manually tested.
• Answered above.

[FeynmanZhou]

+1 to keep the latest weekly dev build. The elder dev build does not make sense for real testing cases as it doesn't include the latest PRs in it.

@dtzar Everyone can easily get the download stats from an open-source project, it's transparent on the Internet. Do we need to remove the screenshot above?

[FeynmanZhou]

@JeyJeyGao I will turn this discussion into a GitHub issue. Can you update the release workflow accordingly?

[JeyJeyGao]

The old release deleting logic added in this PR: #449