Skip to main content
Welcome to the External Pull Request (PR) process for Intent Architect modules. We encourage our community to contribute by submitting pull requests for desired changes in our modules. This guide outlines the complete process from submission to official release.

​
Process Overview

The PR process follows a structured workflow to ensure quality and maintainability:

​
1. Pull Request Submission

We welcome pull requests from anyone for any Intent Architect module, proposing changes they would like to see implemented.
Before submitting your PR, ensure you have:
The module version must be updated according to the Semantic Versioning scheme:
  • MAJOR version for incompatible API changes
  • MINOR version for backwards-compatible functionality additions
  • PATCH version for backwards-compatible bug fixes
Update the version in the module’s .imodspec file.
Ensure the module compiles and installs successfully in Intent Architect. Test the installation process to verify there are no errors.
Add test cases to the Tests Intent Architect solution (Tests/Intent.Modules.NET.Tests.isln). Tests should cover:
  • New functionality you’ve added
  • Edge cases and error scenarios
  • Integration with existing modules
Run the run-pre-commit-checks.ps1 script to ensure your changes pass all validation checks. See Pre-commit Checks below for details.

​
Pre-commit Checks

Before submitting your PR, run the pre-commit validation script: 
.\run-pre-commit-checks.ps1
This script runs multiple phases:
1

Pre-build Validations

Validates module configurations and metadata files.
2

Ensure No Outstanding Changes to Modules

Checks that all module changes are properly tracked.
3

Build All Modules

Compiles all modules to ensure there are no build errors.
4

Ensure No Outstanding Changes to Tests

Verifies test configurations and checks for deviations.
5

Build All Tests

Compiles all test projects to ensure they build successfully.
The script remembers which phases have completed successfully. If a phase fails, fix the issue and re-run the script - it will resume from the failed phase. Use the -Reset flag to start from the beginning:
.\run-pre-commit-checks.ps1 -Reset
When all checks pass, you’ll see:
✅ All checks completed successfully, commit, push and the CI build should hopefully succeed 🤞

​
2. Pull Request Review

Once you submit your PR, our team will review it to ensure it meets the contribution guidelines:

Code Quality

Reviewing code structure, patterns, and adherence to best practices

Functionality

Testing the feature or fix works as intended

Integration

Ensuring compatibility with other modules
As our team will be ultimately responsible for maintaining the module going forward, we may do additional work to bring the change in line with our internal best practices and standards.
Additional work may include:
  • Generalization of code - Making patterns more broadly applicable
  • Release versioning - Finalizing the version number for release
  • Creation of test cases - Adding comprehensive tests and integration scenarios
  • Documentation updates - Ensuring module documentation is current
Once the review is completed, the approved change is merged into our Development branch, and a pre-release version is published.

​
3. Pre-release Published

After merging, a pre-release version of the module is published to allow thorough testing and validation.

​
Pre-release Versioning

Pre-releases follow this versioning pattern: 
{Expected Official Release Version}-pre.*
If the change was to a module named Intent.SomeModule which was currently at version 1.2.0, and the change is considered to be a patch:
  • Pre-release(s): 1.2.1-pre.0, 1.2.1-pre.1, etc.
  • Official release: 1.2.1

​
Testing Pre-releases

Contributors and stakeholders can install pre-release versions to validate:
  • Functionality works as expected
  • No breaking changes to existing projects
  • Integration with dependent modules
  • Performance and stability
Pre-release versions should not be used in production environments. They are for testing and validation purposes only.

​
4. Official Release

Assuming no issues arise during the pre-release testing phase, the pre-release version is promoted to an official release typically within a maximum of two weeks.
This ensures a timely transition from pre-release to a stable and officially endorsed version.

​
Release Timeline

The official release is made available through the Intent Architect module repository and can be installed in production projects.

​
Communication and Updates

Throughout the process:
  • You’ll receive updates on your PR through GitHub notifications
  • Any additional changes made by the team will be communicated
  • You’ll be notified when the pre-release is available for testing
  • The official release will be announced with release notes
Stay engaged with your PR by responding to comments and questions from the review team. This helps expedite the process and ensures your contribution meets all requirements.

​
Next Steps

Contribution Guidelines

Review detailed technical requirements

Get Support

Ask questions or report issues
We value your contributions and look forward to maintaining the quality and integrity of Intent Architect modules through this collaborative process. Thank you for your commitment to excellence!

Build docs developers (and LLMs) love

Get started for freeTalk to us