Delivery

Once you set up the package with your plugin as described here, you now may want to deliver it to ALLPLAN users. You can do it by registering your plugin in the plugin hub . Once it's done, ALLPLAN users can download and install your plugin directly in ALLPLAN via plugin manager

Prerequisites

a GitHub account

Publish your plugin to GitHub

Your plugin must be hosted in a public repository.

Tip

You can use our repository template with predefined folder structure and GitHub workflow for creating a new release.

Create a release

Update the plugin version in the install-config.yml file in the section plugin. E.g. for the very first release, enter 1.0.0.
Create a GitHub release . The tag name connected to the release must match the version in your install-config.yml.
Enter a name for the release, and describe it in the description field. The release name is up to you - we don't put any requirements on this.
Attach the .allep file to the release
You can mark the release as a pre-release. It won't be considered as latest so the user won't get notified when checking for updates. But the release will appear in the list of all available releases, when user tries to install a specific version of the plugin.

Use GitHub actions to create a release

Creating a release might be a hideous task. Here's how you can automate it with a GitHub action, that is triggered every time you create a tag in your repository.

When you used our repository template to create a repository for your plugin, you may have noticed the workflow definition in .github/workflows/release.yml . If you didn't, just create one in your repository. Let's go through what it does:

name: Create release draft

on:
push:
    tags:
    - "*" #(1)!

jobs:
build:
    runs-on: windows-latest #(2)!
    permissions:
    contents: write
    steps:
    - name: Checkout repository
        uses: actions/checkout@v3

    - name: Create allep file #(3)!
        uses: vimtor/action-zip@v1.1
        with:
        files: Library/ PythonPartsScripts/ install-config.yml
        recursive: false
        dest: SampleExtension.allep #(4)!

    - name: Create release draft #(5)!
        env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: |
        $tag = "${{ github.ref_name }}"

        gh release create "$tag" `
            --title="$tag" `
            --draft `
            SampleExtension.allep #(6)!

The workflow is triggered each time a new tag is created
It's important to run it on windows because of how git handles new line characters on linux, which may then cause problems in ALLPLAN
This step creates the ZIP archive bein the Allep file. Specify all the files and directories you want to put into your Allep package, in the files key separated with space character. Note, that directories are followed by a trailing slash /
Specify the name of the .allep file. The only requirement is for it to have an .allep extension.
This step creates a release draft. Draft means, that it won't be published, until you click the publish button. Release name will be equal to the tag name and the .allep file will be attached to it.
Don't forget to adapt the name of your .allep file here as well!

Now, to trigger the action, just create an annotated tag whenever you think it's a good moment to publish an update of your plugin:

git tag -a 1.0.1 -m "1.0.1"
git push origin 1.0.1

After the push, the action should start. It may take a couple of seconds until it's done. After that, you should be able to see a new release draft created under https://github.com/your-username/your-repo-name/releases. What you need to do is provide the description and click on publish.

Submit your plugin for review

Make sure, you are on the right branch of the plugin hub repository for the ALLPLAN version you want to submit your plugin to. If you follow the links in this tutorial, you will submit your plugin for the version 2026.
If you are submitting your very first plugin, add the details about your organization in plugin-developers.json as a new entry at the end of the file:
```
{
    "id": "example-developer", //(1)!
    "name": "Sample Developer Ltd.", //(2)!
    "address": {
        "street": "123 Main Street",
        "city": "Sample City",
        "zip": "12345",
        "country": "Sampleland"
    },
    "homepage": "https://www.sampledeveloper.com",
    "support": {
        "email": "support@sampledeveloper.com", //(3)!
        "telephone": "+1 234 56789",
        "languages": [
            "eng",
            "deu"
        ]
    }
}
```
1. Slugified name, you want to be identified with. Make sure, it's not occupied by another entry in the JSON. It should match the developer name specified in the plugin section in the install-config.yml file.
2. The user friendly name of your organization, that will be shown to the user.
3. Providing an e-mail for technical questions of the users is mandatory. All other entries are optional.
Mandatory fields: id, name, support (only the email, others optional).
Optional fields: all others.
In allplan-extensions.json add a details about your plugin as a new entry at the end of the JSON array:
```
{
    "uuid": "00000000-0000-0000-0000-000000000000", //(1)!
    "name": "Sample Plugin Name", //(2)!
    "developer": "example-developer", //(3)!
    "description": "A brief description of what your plugin does.", //(4)!
    "github": { //(5)!
        "owner": "your-github-username",
        "repo": "your-plugin-repo-name"
    },
    "compatibility": ">=2.0.0" //(6)!
}
```
1. Replace with the UUID of your plugin, specified in the plugin section in the install-config.yml file.
2. User-friendly name of your plugin. It should match the name specified in the install-config.yml file.
3. Your slugified developer id.
4. One-line description of your plugin.
5. The data of the repository, where the plugin is hosted. If the URL of the repository is like https://github.com/max-mustermann/nice-plugin, then the entry will be:
```
"github": {
    "owner": "max-mustermann",
    "repo": "nice-plugin"
}
```
6. This entry is optional. Specify it, if only certain versions of your plugin work with the ALLPLAN version you are submitting your plugin to. If that's the case, provide a version specifier¹, that matches these compatible plugin versions. For example:
  - Versions of your plugin prior to 2.1.0 don't work in ALLPLAN 2026. In this case, on the branch 2026 of the plugin hub repository specify:
    "compatibility": ">=2.1.0"
  - Only the major versions 3.X.X of your plugin works in ALLPLAN 2026. Versions 4.X.X and newer and 2.X.X or lower don't. In this case, on the branch 2026 of the plugin hub repository specify:
    "compatibility": "~=3.0"
Optional fields: compatibility.
Mandatory field: all others.
Select Commit changes... in the upper-right corner.
Select Propose changes.
Select Create pull request.
In the name of the pull request, enter "Add plugin: XXX" (where XXX is the name of your plugin) and create the request.

Now sit back and wait until we review your plugin.

Note

Note, that you have just added a new plugin, that will appear in ALLPLAN 2026. To add a plugin to other versions, you have to add similar entries on other branches of the plugin hub repository

Address the reviewer comments

Once we reviewed your plugin, we will add comments to your pull request. Address them by updating your release and let us know you're done by adding a comment. No need to create a new pull request.

Once we've verified, that all the issued were addressed, we will merge your PR and your plugin will be published. From that moment, all ALLPLAN users can install it.

The version specifiers we expect are the same as the ones you would use in a requirements.txt file. Refer to PIP documentation ↩

Placeholder