Use tags and GitHub releases for packages (vip files)

[MathieuR-Iolas]

VIP / Artifact Handling
I want to test AF OS last packages. I have to admit that it's complicated for me to find out which package to install. I didn't read all the AF open source track on AF Guild discord, I guess I will find the info here...
On the other hand, I'm a bit surprised to find VIP package into source code repository. I usually do not version build results (exe, installer, vip, nipkg, ...) as long as I can clearly identify the source code used to get that build (usually a commit, or better, a tag).

Quick and easy improvement: use git tags + GitHub Releases
I think it could be great to use git tags plus associated GitHub release to make clear what is the last available release.

I suggest two steps to slightly change the way of doing things on AF OS repo :

• For future releases, create a tag of the repo on the commit that allow you to build a package (vip).
  Tag naming convention has to be clearly defined (version of the package - it can be an alpha, beta, etc.).
  Finally create a GitHub Release, linked to that tag and attach the built VIP files.
• For existing releases (if relevant), identify the commits used to create the existing builds, make tags on these commits, create releases linked to that tags, and finally remove and do not version anymore the vip files (*.vip in .gitignore)

Doing so, you are also preparing the job for a potential CI process: you may want start the build process when a tag is pushed to GitHub for instance. And let it build on a dedicated build machine (can't say anymore "that works on my computer, haha").

[svelderrainruiz]

@MathieuR-Iolas this makes a lot of sense and a considerable improvement to the way i initially handled the release, i will apply your idea to all open source repos NI has from now on.

I will convert this GitHub issue into a discussion since i am planning on creating multiple granular GitHub issues. You will see that the github issue is closed, but that is only because it was converted into a discussion.

[niACS]

Tl/dr: No objections, but the packages need to be continuously available somewhere.

I took the route of adding the packages so that they were immediately available to anyone who wanted them, including people who are testing the install/uninstall functionality. If not having the packages in the repo is better practice, then we should probably do that.

**Before we take that step, the release packages need to be moved to an appropriate sharing repository, either LabVIEW Tools Network or VIPM.io. I can post them to VIPM.io if we'd like, but they'd be under my name. NI can post them there as well, or easily put them in the Tools Network. Either solution works for me.

actor_framework_2024_for_2020-1.0.0.8.vip and actor_framework_project_providers_2024_for_2020-1.0.0.4.vip are the correct latest packages associated with main.

actor_framework_project_providers_2024_for_2020-1.1.0.10.vip is the correct latest package for the providers for develop. I have an edit to make to the package for the core code, so we don't yet have a package to publish for that. I will have that done in the next few days.

I am not married to these package names, if we want to change them.