Building Your Own Installomator, Part 2: Branches, Cadence, and Choosing a Workflow Level

02 Jul Building Your Own Installomator, Part 2: Branches, Cadence, and Choosing a Workflow Level

Forking, curating labels, and packaging an internal build

Part 2 of a 4-part series

Part 1 covered why you might fork Installomator at all and gave a quick-start path to a working package. This post is about the decisions that come before you write any code: what main vs release actually means, and how much process your team really needs.

Latest Release vs Beta / Main Branch

Installomator uses its branches in a way that is important for Mac admins to understand. The upstream README states that the default main branch is the beta version of the next release, which you can read in full in the project README. It contains the latest fixes, new labels, and label changes, but those changes may not be as thoroughly tested as a formal release.

Worth a clarification here, because the word “beta” tends to scare people off of main for the wrong reason: labels are fully reviewed and approved before they merge into main. “Beta” describes where main sits in the versioning and packaging cadence, not a lower bar of review. No additional validation happens to a label after it lands on main and before a formal release is cut. In practice, upstream is shipping code “releases” (merges to main) multiple times a week, but only builds and signs an actual .pkg release every few months. If you are blocked from using main by a policy that requires a “release,” it is worth clarifying with whoever owns that policy whether the concern is really about review rigor (already satisfied) or about pinning to a specific, reproducible version (which your own fork and build process solves just as well as waiting for an official package).

In practical terms:

• Latest release (e.g., stable version 10.8): use the GitHub Releases page or the release branch. This is the safer choice for most production environments.
• Latest beta / newest labels (e.g., the upcoming 10.9 beta): use the default main branch. This is where you go when you need the newest label changes before the next formal release.
• Your internal build: use your fork or branch after you have pulled, reviewed, tested, and assembled the version you want.

So when someone says, “I want the latest labels,” ask which kind of latest they mean:

• Latest stable release?
• Latest main branch/beta label updates?
• Latest reviewed internal build?

Those are different deployment decisions.

Match the Workflow to Your Needs

Not every team needs the same level of process. Before you build branches, packages, and release workflows, decide what problem you are actually solving.

Basic Need: I Just Want the Latest Beta and Labels

This is the lightest workflow. You mostly want current Installomator code and the latest labels from the upstream main branch, understanding that main is the beta / next-release branch where work for releases after 10.9, such as 10.10 will appear first.

Use this when:

• You trust the upstream project for most labels.
• You want newer labels before the next formal package or internal release cycle.
• You are comfortable testing a label before using it in production.
• You do not need to remove most of the label catalog.

A basic workflow might be:

git clone https://github.com/Installomator/Installomator.git
cd Installomator
./assemble.sh --script
sudo ./Installomator.sh zoom DEBUG=1

If you prefer GitHub Desktop, the same workflow looks like this:

1. Open GitHub Desktop.
2. Choose File > Clone Repository.
3. Select the URL tab and enter:

https://github.com/Installomator/Installomator.git

4. Clone the repo somewhere predictable.
5. Open the cloned repository folder in Terminal.
6. Build and test from that folder:

./assemble.sh --script
sudo ./Installomator.sh zoom DEBUG=1

Do not skip the ./assemble.sh --script step, even though the repo already contains a root Installomator.sh file. Upstream only rebuilds and commits that root script “for release,” which happens on its own irregular cadence, not on every merge to main. A fresh clone’s checked-in root script can lag behind the fragments by months. Running assemble.sh --script yourself rebuilds it from the current fragments, which is the whole point of working from main in the first place.

If the test looks good, use the latest built script in Jamf Pro or your MDM. This model is less about maintaining a long-lived fork and more about running the current project with the labels you need.

If you want the latest stable release instead, use the GitHub Releases page or the upstream release branch rather than main.

Intermediate Need: I Want Reviewed Updates and an Internal Build

This is where a fork becomes useful. You still want upstream improvements, but you do not want every upstream change to land on managed Macs automatically.

Use this when:

• You want to pull selected label updates from upstream.
• You want to tag known-good internal builds.
• You want to upload a reviewed Installomator.sh to Jamf Pro.
• You may want to build your own installer package occasionally.

An intermediate workflow usually looks like:

git fetch upstream
git switch production
git checkout upstream/main -- fragments/labels/zoom.sh
git diff
git commit -m "Update zoom label from upstream"
./assemble.sh --script

In GitHub Desktop, the same idea is:

1. Open your internal Installomator repo in GitHub Desktop.
2. Switch to your production branch.
3. Fetch from the remote so GitHub Desktop knows about the latest upstream-tracking branch state.
4. Bring the updated label file into your production branch. Depending on how your repo is set up, that may mean copying the label from an upstream-tracking branch in your editor, or using Terminal for just this one targeted checkout:

git checkout upstream/main -- fragments/labels/zoom.sh

5. Review the changed label in GitHub Desktop’s diff view.
6. Commit with a clear message:

Update zoom label from upstream

7. Build from Terminal:

./assemble.sh --script

This gives you a review point before the updated label becomes part of your internal deployment.

Advanced Need: I Want a Curated or Custom Distribution

This is the full internal distribution model. You are not just consuming Installomator; you are maintaining your organization’s version of it.

Use this when:

• You want a smaller approved label set.
• You maintain custom internal labels.
• You override upstream labels for local policy reasons.
• You package Installomator locally with munkipkg or another packaging workflow.
• You use wrapper scripts or Jamf Pro (or other MDM) parameters to call the installed local script.
• You want a repeatable release process with tags, testing, and rollback.

An advanced workflow might have separate branches for upstream tracking, production, label testing, and packaging. It may also produce an internal package, such as:

Installomator-Curated-2026.07.01.pkg

This is more work, but it gives you the most control.

Three Common Operating Models

There are really three related workflows that get described as “forking Installomator.”

1. Smaller Curated Label Set

This is the most controlled model. Your production branch contains only the labels you approve and use.

Use this when:

• You want a smaller script.
• You want to reduce the review scope.
• You do not want every upstream label available in production.
• You want explicit approval before a new application can be installed.

In this model, your fragments/labels folder is intentionally small.

2. Current Upstream Labels, Repackaged Internally

In this model, you mostly trust the upstream label catalog, but you still want to build, sign, package, or deploy your own internal copy.

Use this when:

• You want the latest label updates.
• Your Jamf Pro or MDM workflow expects an internal script or package.
• You want to test and tag a known-good internal build.
• You want a local installed copy at /usr/local/Installomator/Installomator.sh.

Here, the fork is less about removing labels and more about controlling release timing. You might pull from upstream often, run tests, then publish a new internal script or package.

3. Custom or Override Label Set

This model is for labels that are local to your environment.

Use this when:

• You have internal apps.
• You need a different download source than upstream.
• You need environment-specific settings.
• You want to override a public label without waiting for an upstream PR.

This can be combined with either of the first two models. A lot of teams end up with a mostly-upstream build plus a handful of local overrides.

Recommended Repo Strategy

For most teams, I would start with three branches and add more only if the workflow needs it:

main

Your tracking branch for upstream Installomator is kept close to Installomator/Installomator.

production

Your internal production branch. Depending on your model, this may be a smaller curated label set, a repackaged upstream build, or an upstream build plus local overrides.

label-testing

A scratch branch for trying new or changed labels before promoting them.

For example, a team that wants both a current upstream package and a smaller lab-safe build might use:

production-full

for an internally packaged copy of current upstream labels, and:

production-curated

for a smaller label set used in sensitive environments.

You can name these whatever makes sense. The point is to separate upstream tracking from your production distribution.

This branch model works whether your internal repo is a normal public GitHub fork or a private mirror. If your organization needs to keep custom labels, internal URLs, or packaging work private, create a private repo for your internal copy and keep the public Installomator project configured as upstream. Part 1 covers that private-repo setup in more detail.

---

Next in this series: Part 3 gets hands-on — how to actually pull labels from upstream, curate your label set, and review changes using the GitHub web interface, GitHub Desktop, or the Git command line, whichever fits how you work.