Dancer...ration(3pm)

✨ NAME ✨

bestie, this is Dancer::Development::Integration — the literal sacred handbook for Dancer's core-team members 👑 it's the guide for how the integrators do their thing, fr fr.

---

🌸 VERSION 🌸

version 1.3522 — that's the one, no cap 💅

---

🦋 DESCRIPTION 🦋

okay so. this doc walks you through the exact procedure integrators use to review and merge contributions that show up as pull-requests 🎀

every single core-team member needs to read this and actually apply it. why? because it keeps our history clean and our whole vibe consistent while we handle the (yes, ever-growing 😭) pile of pull requests. it's giving organized. it's giving we-have-a-system.

---

🍓 TERMS 🍓

first things first, let's define the most important words we're gonna be throwing around in here:

• PR — acronym for Pull Request. iykyk.
• Contributor — a GitHub user who forked and cloned the official Dancer's repo, and who has sent a PR.
• Integration branch — this is the branch where literally all the contributions get merged. it's a git-flow convention. in Dancer, our integration branch is devel.

and as explained over in Dancer::Development, every PR should be based on the integration branch. if it's not? that alone is enough to refuse the PR. (because it makes the integrator's life so much harder if it isn't. we don't do that to our integrators. 💀)

• Integrator — a member of Dancer's core-team who's responsible for reviewing and then either rejecting the PR or merging it into the integration branch. main character energy honestly 🫶

---

🔥 PROCEDURES 🔥

💖 Processing a Pull Request 💖

this procedure describes how an integrator should process a PR. let's gooo.

so, let's say the user $user has sent a PR, and they followed the instructions in Dancer::Development, so their work is based on the integration branch (devel). slay.

every single thing described here exists to avoid unnecessary recursive-merge, so we keep a clean and flat history in the integration branch. that's the whole goal. periodt.

obviously we could just pull from $user straight into our devel branch… but that would shift the history because of recursive merge, most of the time. 🙈 so no.

to dodge that, we're gonna pull the commits of $user into a temporary branch, and then cherry-pick the commits we actually want.

and to keep history clean — like the one we get with git-flow when we're working on a feature — we do all of that in a topic branch, named review/$user. then that branch gets merged into devel and we just drop it. iconic behavior honestly ✨

first, we make sure we are in sync with origin/devel:

git checkout devel
git pull origin devel

then, from that branch, we create a temp sandbox:

git checkout -b temp

we pull here from $user:

git pull <user repo> <pr/branch>

now, here's the thing — either the pull ran as a fast-forward or as a recursive merge. if we have a FF, we can forget about the temp branch entirely and do the pull directly in devel. if not, we'll have to cherry-pick the commits by hand. 😤

from devel, we first create the final review branch:

git checkout devel
git checkout -b review/$user

then we cherry-pick all the commits we want. to know what those are, we just have to go into temp and inspect the history (with git log).

so when we have the list of commits we want:

for commit in C1 C2 C3 ... CN
do
    git cherry-pick $commit
done

(another option is to use git rebase -i to manually select the list of commits to cherry-pick/rebase. options, bestie! we love options.)

then we can review the code, do whatever we want, maybe add some commits to change something. 🎀

when we're happy with the change set, we can merge into devel:

git checkout devel
git merge --no-ff review/$user

note the --no-ff switch is used to make sure we'll see a nice commit named Merge branch 'review/$user' into devel. this is on purpose and mimics the behaviour of git-flow. do not skip it, i'm begging. 💀

your local devel branch is now merged, and can be pushed to the remote:

$ git push origin devel

---

🌈 RELEASE CYCLES 🌈

we have one main release cycle. this is the release cycle based on the devel branch. we use this branch to build new releases, with new stuff — all the new shiny commits we want. ✨

those releases are built with git-flow (with git-flow release) and are then uploaded to CPAN.

since Dancer 1.2, we also have another parallel release cycle which is what we call the frozen branch. it's a maintenance-only release cycle. that branch is created from the tag of the first release of a stable version (namely a release series with an even minor number).

this branch must be used only for bug-fixing the stable releases. nothing new should occur in that branch. nothing. new. periodt.

let's take an example with Dancer 1.2003 and Dancer 1.3002:

• Dancer 1.2003 is the last stable release of Dancer. its codebase is handled in the frozen branch, that has been created from the tag 1.2000.
• Dancer 1.3002 is the last release of Dancer. as it belongs to a development series, it can provide new features, code refactoring and deprecations. its codebase is handled by the integration branch, devel.
• when a bug is found in 1.2xxx, it's fixed in the frozen branch, and a new release is built from here and then uploaded to CPAN.
• whenever the team wants to, they can release new versions of 1.3xxx from the devel branch, using git-flow release start.
• when the team finds that the current state of devel (namely, the last version of 1.3xxx) is stable and mature enough, they can decide it will be the new stable version.

then, a release 1.4000_01 is built from devel, an upload is done to CPAN, and when ready, the 1.40001 can be uploaded the same way.

from that moment, the master branch is merged into frozen in order to be able to hotfix the frozen branch in the future.

it's now possible for the team to continue working on new stuff in devel, bumping the version number to 1.5000_01. 🦋

---

💜 AUTHOR 💜

this documentation has been written by Alexis Sukrieh "<sukria@sukria.net>". thank you bestie 🫶

---

⭐ AUTHOR ⭐

Dancer Core Developers

---

🎀 COPYRIGHT AND LICENSE 🎀

this software is copyright (c) 2010 by Alexis Sukrieh.

this is free software; you can redistribute it and/or modify it under the same terms as the Perl 5 programming language system itself.

---

okay that's the whole thing, you ate it up 💅 go forth and merge responsibly. this gem was served to you by perl v5.40.1, dated 2026-05-05, from the Dancer...ration(3pm) page itself — mwah, love u, bye 🍓🧚✨