Need a publicly visible release plan

[triplepoint]

When you compare the commit history of the firmware or Slic3r repositories to the commit history of this repo, it quickly stands out that this repository is lacking a release plan that the public can follow.

Specifically, the software repos use Git tagging to denote which Git commits map to which official releases.

In contrast, it's not possible to identify which Git commits in this repository correspond to the zip file packages listed on https://www.prusa3d.com/prusa-i3-printable-parts/, or if the models in the zip files are even from this Git repository.

I can confirm by inspection that the STL files in the most recent commit of the mk3 branch of this repo do not match the mk3 zip file from the printable parts page.

I understand that the workflow for developing model files is different from developing software. I understand that with solid model design tools, the models are stored in a separate system from Git. But the public doesn't have access to that internal store; all we can see is the Git repository. It's important, as an open source project, to ensure that all changes to the design go into Git before they're released, and not as a follow-up procedure.

We need:

1. The procedure for creating a new release of these models must start with pushing the changes to this Git repository. All subsequent steps of the release checklist should only access files which have first been committed here, to ensure uncommitted files are not making it into a release package.
2. Official release-to-production releases need to be git-tagged with release versions, so that we know which Git commit represents which downloadable release.
3. Release archive files (the files from the dowloadable parts page) need to contain the version - either in the archive file name or in a manifest file somewhere inside the archive.
4. Release archives need to only contain files from a single commit of this Git repository, and not be cherry-picked from different branches, different commits, or uncommitted files.
5. Any re-packaging necessary for a release needs to be done with automation scripts which are stored in this repo, so that we can be confident in the procedure which generates a release. This includes any filtering of files, renaming of files, moving of files, modifications to files, generation of new files, etc.

These are all basic features of an open-source project, and the goal is summarized as "make sure work isn't happening that isn't eventually released to the public, and make sure people can trace how each release package was produced". Hopefully it's obvious how this is a good thing for everyone involved.

Linking to a relevant Prusa forums post:
https://shop.prusa3d.com/forum/hardware-firmware-and-software-help-f64/3d-model-release-plan-and-the-parts-git-repo-in-ge-t23803.html