pib Stable Releases

Summary

Create a separate Onshape document for each stable release of the Printable Intelligent Bot (pib) to enable users to print their own bots while allowing for continuous development and improvements.

Description

The pib project is in active development, with several branches working on different improvements. To give users a stable and reliable experience, we will create a separate Onshape document for each stable release by copying the main document. This approach lets users start printing their own bots without being affected by ongoing development.

We will use the FeatureScript "pib Part-Number" to add revisions, like "23.06", and dates to all parts in a stable release. This will help users track changes and updates. If we provide a hotfix, we will add the current date to each fixed part. This way, users can know which parts need to be reprinted.

Why this is a good idea:

1. Stability for users: Users can print their own bots without worrying about ongoing development or errors in the geometry.

2. Easier maintenance and support: Separate documents for stable releases make it easy to provide hotfixes to fix errors or issues.

3. Clear versioning: Separate documents for each stable release help track and communicate version changes.

4. Reduced risk of accidental changes: Keeping stable releases separate from the main development document reduces the chance of accidental changes.

5. Predictable release schedule: Two stable releases per year help users plan and know when to expect new features and improvements.

6. Version control and traceability: Using the FeatureScript "pib Part-Number" helps users track changes and updates in stable releases.

Tasks:

1. Create a new Onshape document for the upcoming stable release by copying the main development document.

2. Review and test the geometry in the new document to ensure it is error-free and ready for printing.

3. Implement the FeatureScript "pib Part-Number" in the stable release document to add revisions and dates to each part.

4. Update any relevant documentation and user guides to explain the use of revisions and dates in the stable release, and how users can identify updated parts in the event of a hotfix.

5. Train the development team on how to properly use the FeatureScript "pib Part-Number" for revisions and dates in stable releases.

6. Prepare a communication plan to announce the stable release, including any necessary marketing materials, blog posts, or social media updates.

7. Implement a process for users to report any errors or issues they encounter with the stable release.

8. Develop a plan for providing hotfixes to address any issues identified by users in the stable release.

9. Establish a clear release schedule, including the target dates for the next stable release.

10. Continuously monitor user feedback and iterate on the stable release process as needed.

Done Criteria:

• A new Onshape document is created for each stable release.

• Stable releases are tested and confirmed to be error-free before being made available to users.

• The FeatureScript "pib Part-Number" is implemented in the stable release document and used to add revisions and dates to each part.

• Users are provided with clear guidance on how to identify updated parts in the event of a hotfix.

• The development team is proficient in using the FeatureScript "pib Part-Number" for revisions and dates in stable releases.

• A predictable release schedule is established and communicated to users.