ভালো commit, tag আর release — Conventional Commits, SemVer আর changelog

১ · ভালো commit কী — ইতিহাস যেন পড়া যায়

পর্ব ৮-এ (প্রথম Git repository) প্রথম commit করেছেন, আর সেখানেই দেখেছেন atomic commit-এর ধারণা: একটি commit-এ একটি যুক্তিসংগত পরিবর্তন। এই পর্বে প্রশ্নটি আরেক ধাপ এগিয়ে: commit-গুলো একসাথে যখন একটি project-এর ইতিহাস হয়, আর সেই ইতিহাস থেকে যখন একটি version নম্বর, একটি release আর ব্যবহারকারীদের জন্য পরিবর্তনের তালিকা বানাতে হয় — তখন “ভালো” মানে কী?

অভিজ্ঞ দলগুলো ভালো commit-কে সাধারণত চারটি গুণে চেনে:

এই চারটি গুণ আলাদা নয়। Commit ছোট আর এক-উদ্দেশ্যের হলে “কেন” লেখা সহজ, কারণ একটিই কারণ আছে। আবার প্রতিটি commit-এ build সবুজ রাখার অভ্যাস থাকলে একটি “কাজ চলছে” ধরনের commit মূল branch-এ পৌঁছায় না। নিজের branch-এ ইচ্ছেমতো ছোট “wip” commit করা দোষের নয় — ভাগ করার আগে interactive rebase-এর fixup আর --autosquash দিয়ে সেগুলো গুছিয়ে নেওয়া যায় (পর্ব ১৫ — Rebase), কিংবা pull request merge করার সময় squash করা যায় (পর্ব ১৬ — Pull request আর fork). আর একটি পরিবর্তনের অংশগুলো আলাদা commit-এ ভাগ করার হাতিয়ার git add -p দেখেছেন পর্ব ৮-এ।

এই পর্বের সব Git আউটপুট আসল — একটি খালি পরীক্ষার folder-এ Git ২.৫৩ দিয়ে চালানো। লেখক “Rahim” (rahim@example.com), আর প্রতিটি commit ও tag-এর সময় GIT_AUTHOR_DATE/GIT_COMMITTER_DATE দিয়ে ২০২৬-০১-১৫ সকাল ১০:০০ (+06:00) থেকে এক মিনিট করে বাড়িয়ে ঠিক করা, যাতে hash আপনার যন্ত্রেও একই আসে। গল্পটি একটি কাল্পনিক আন্তঃজেলা বাসের টিকিট অ্যাপ — ঈদের আগের ভিড়ে যার ওপর অনেক চাপ। শুরুতে দুটি commit: e6e2912 (feat: add fare calculator) আর 1674d4e (docs: add README), যেখানে প্রথম release v1.0.0 দেওয়া হয়েছে।

২ · Commit message-এর গঠন — ৫০/৭২, আদেশসূচক ক্রিয়া আর trailer

একটি commit message-এর তিনটি অংশ: প্রথম লাইন (subject বা সারাংশ), একটি ফাঁকা লাইন, তারপর body. শেষে ঐচ্ছিকভাবে কিছু “Key: value” লাইন। প্রচলিত নির্দেশিকাগুলো (Git project-এর নিজের SubmittingPatches নির্দেশনা, আর ২০০৮ সালের দিকে Tim Pope-এর একটি জনপ্রিয় blog লেখা থেকে ছড়ানো “৫০/৭২” রীতি) মোটামুটি এমন:

Imperative mood নিয়ম ইংরেজি বার্তার জন্য। বাংলাভাষী দলগুলোর অনেকে — আমাদের ধারণা, বেশিরভাগই — commit message ইংরেজিতে লেখেন: কোড, টুল আর open-source অবদান ইংরেজিতে, আর দলে বিভিন্ন ভাষার মানুষ থাকতে পারেন। বাংলায় লিখলে Git-এর আপত্তি নেই (Git UTF-8 রাখে), কিন্তু কিছু পুরোনো টুল, terminal বা email ব্যবস্থায় অক্ষর ভাঙতে পারে, আর অক্ষর গোনার হিসাবও আলাদা হয়। যা-ই বাছেন, দলের নিয়মে লিখে রাখুন। এই পর্বের সব উদাহরণ ইংরেজিতে।

এলোমেলো commit থেকে ভালো বার্তা — ধাপে ধাপে

রাতের শেষে একজন developer তিনটি কাজ একসাথে commit করতে যাচ্ছিলেন: ভাড়া গোল করা, README-র একটি বানান ঠিক করা, আর ভুলে থেকে যাওয়া একটি debug লাইন। নিচের stepper-এ সেটিকে কীভাবে গোছানো হলো দেখুন:

আসল repository-তে প্রথম commit-টি এভাবে হলো (-F দিয়ে একটি ফাইল থেকে বার্তা নেওয়া; সাধারণত git commit চালালে editor খোলে, সেখানেই লেখেন):

$ cat ../msg3.txt
fix(fare): round fare to whole taka

Counters cannot give change in paisa, so a fare like 387.50
confused passengers and cashiers. Round to the nearest taka.

Refs: #17
$ git commit -F ../msg3.txt
[main 30ee2e5] fix(fare): round fare to whole taka
 1 file changed, 1 insertion(+), 1 deletion(-)

Issue-এর উল্লেখ আর trailer

বার্তার শেষ অনুচ্ছেদে Key: value আকারের লাইনগুলোকে Git বলে trailer — ইমেইলের নিচের স্বাক্ষর-অংশের মতো। Git নিজে কয়েকটি বোঝে, আর git interpret-trailers ও %(trailers) format দিয়ে সব পড়া যায়। প্রচলিত কয়েকটি:

• Refs: #42 বা Fixes: #42 — issue tracker-এর issue-এর সূত্র। কিছু hosting platform বার্তায় Closes #42 বা Fixes #42 লেখা থাকলে মূল branch-এ ঢোকার পরে issue নিজে বন্ধ করে দেয় (শব্দ আর নিয়ম platform-ভেদে আলাদা, লেখার সময়ের অবস্থা দেখে নিন)।
• Co-authored-by: Name <email> — একসাথে বসে লেখা (pair programming) কোডে সহলেখকের নাম। Git-এর কাছে এটি শুধু লেখা; কিছু platform একে চিনে সহলেখককেও কৃতিত্ব দেখায়।
• Signed-off-by: Name <email> — git commit -s (--signoff) নিজের নাম দিয়ে এটি যোগ করে। অর্থ: “আমি এই কোড জমা দেওয়ার অধিকার রাখি” — Linux kernel-সহ অনেক project-এ Developer Certificate of Origin (DCO)-এ সম্মতি এভাবে জানানো হয়। এটি cryptographic স্বাক্ষর নয়; যে কেউ যেকোনো নাম লিখতে পারে। আসল স্বাক্ষর (-S, GPG/SSH) পর্ব ৫৭-এ।

# (seat.js added and staged; ../msg4.txt ends with "Refs: #42" and
#  "Co-authored-by: Karim <karim@example.com>")
$ git commit -s -F ../msg4.txt
[main b6ea870] feat(seat): let passengers ask for a window seat
 1 file changed, 6 insertions(+)
 create mode 100644 seat.js
$ git log -1
commit b6ea870de0cc17925ea2b4a80789045caeda0704
Author: Rahim <rahim@example.com>
Date:   Thu Jan 15 10:04:00 2026 +0600

    feat(seat): let passengers ask for a window seat

    Many passengers on long Eid trips want a window seat, and the
    counter staff were choosing seats by hand. pickSeat() now takes
    a wantWindow flag and falls back to any free seat.

    Refs: #42
    Co-authored-by: Karim <karim@example.com>
    Signed-off-by: Rahim <rahim@example.com>
$ git log -1 --format="%(trailers)"
Refs: #42
Co-authored-by: Karim <karim@example.com>
Signed-off-by: Rahim <rahim@example.com>

৩ · Conventional Commits 1.0.0 — যন্ত্রও যেন পড়তে পারে

ভালো বার্তা মানুষের জন্য। কিন্তু release-এর সময় একটি প্রশ্ন যন্ত্রকেও জিজ্ঞেস করতে চাই: “শেষ release-এর পরে কি নতুন সুবিধা এসেছে? কিছু ভেঙেছে?” এজন্য বার্তার প্রথম লাইনের একটি নির্দিষ্ট ব্যাকরণ — Conventional Commits. এর ১.০.০ সংস্করণের spec (আমাদের জানা মতে ২০১৯ সালে প্রকাশ, AngularJS project-এর commit নির্দেশিকা থেকে অনুপ্রাণিত) ছোট আর নির্দিষ্ট:

• type বাধ্যতামূলক। spec নিজে শুধু দুটির অর্থ বাঁধে: feat = নতুন সুবিধা (SemVer-এর MINOR-এর সাথে মেলে), fix = bug সারানো (PATCH). বাকি type অনুমোদিত; প্রচলিত তালিকা (Angular রীতি আর commitlint-এর প্রচলিত config থেকে): docs, refactor, test, chore, perf, ci, build, style, revert.
• scope ঐচ্ছিক, বন্ধনীর ভেতরে একটি বিশেষ্য: কোডের কোন অংশ — fix(fare):, feat(seat):.
• description কোলন আর একটি space-এর ঠিক পরে; ছোট সারাংশ।
• body description-এর পরে একটি ফাঁকা লাইন দিয়ে শুরু; মুক্ত লেখা।
• footer Git trailer-এর রীতিতে (Token: value বা Token #value). বিশেষ footer BREAKING CHANGE: … (বড় হাতের অক্ষরে; BREAKING-CHANGE সমার্থক)।
• ! — type/scope-এর পরে, কোলনের আগে: এটিও breaking change-এর চিহ্ন। ! থাকলে footer ঐচ্ছিক; description-ই তখন কী ভাঙল তা বলে।

আমাদের অ্যাপে পরের বড় পরিবর্তন: ভাড়া আর কিলোমিটার-সূত্রে নয়, রুট-ভিত্তিক তালিকা থেকে। ফলে fare(km) হয়ে গেল fare(from, to) — যে কোড পুরোনো রূপে ডাকত, সেটি ভাঙবে। বার্তায় দুইভাবেই তা বলা হলো:

feat(fare)!: read fares from a route table

Fares now come from fares.json per route instead of a per-km
formula, because the operator sets a fixed price per route.

BREAKING CHANGE: fare(km) is now fare(from, to).

দলগুলো সাধারণত এই নিয়ম যন্ত্র দিয়ে যাচাই করে — commit-এর আগে একটি Git hook-এ (পর্ব ৫৬) বা CI-তে (পর্ব ৫৮) একটি commit linter চালিয়ে। নিচে একটি ছোট linter, যা type, দৈর্ঘ্য, ফাঁকা লাইন আর imperative mood যাচাই করে। শেষ নিয়মটি নিছক অনুমান (heuristic) — খেয়াল করুন সেটি কোথায় ভুল করে:

// A tiny commit-message linter: type prefix, 50/72 lengths, blank line, imperative mood (heuristic).
const TYPES = ["feat", "fix", "docs", "style", "refactor", "perf", "test", "build", "ci", "chore", "revert"];
function lint(msg) {
  const lines = msg.split("\n"), subject = lines[0], problems = [];
  const m = /^(\w+)(\([\w-]+\))?(!)?: (.+)$/.exec(subject);
  if (!m) problems.push("no 'type(scope): description' prefix");
  else if (!TYPES.includes(m[1])) problems.push(`unknown type '${m[1]}'`);
  if (subject.length > 72) problems.push(`subject ${subject.length} chars (error > 72)`);
  else if (subject.length > 50) problems.push(`subject ${subject.length} chars (aim for <= 50)`);
  if (subject.endsWith(".")) problems.push("subject ends with '.'");
  const firstWord = (m ? m[4] : subject).split(" ")[0].toLowerCase();
  if (/(ed|ing)$/.test(firstWord)) problems.push(`'${firstWord}' looks non-imperative`);
  if (lines.length > 1 && lines[1] !== "") problems.push("line 2 must be blank");
  lines.slice(2).forEach((l, i) => {
    if (l.length > 72) problems.push(`body line ${i + 3} is ${l.length} chars (> 72)`);
  });
  return problems;
}
const samples = [
  "feat(seat): let passengers ask for a window seat",
  "Fixed the bug.",
  "fix: updated the fare rounding for all routes in the Dhaka division",
  "docs: adding README\nexplains how to book",
  "feat: embed the seat map in the ticket page",
  "refactor(fare)!: drop fare(km)\n\nBREAKING CHANGE: callers must pass from and to.",
];
for (const s of samples) {
  const p = lint(s);
  console.log((p.length ? "FAIL " : "ok   ") + JSON.stringify(s.split("\n")[0]));
  p.forEach(x => console.log("       - " + x));
}

ok   "feat(seat): let passengers ask for a window seat"
FAIL "Fixed the bug."
       - no 'type(scope): description' prefix
       - subject ends with '.'
       - 'fixed' looks non-imperative
FAIL "fix: updated the fare rounding for all routes in the Dhaka division"
       - subject 67 chars (aim for <= 50)
       - 'updated' looks non-imperative
FAIL "docs: adding README"
       - 'adding' looks non-imperative
       - line 2 must be blank
FAIL "feat: embed the seat map in the ticket page"
       - 'embed' looks non-imperative
ok   "refactor(fare)!: drop fare(km)"

৪ · Tag — lightweight আর annotated

পর্ব ১২-এ (Branch — pointer, HEAD, switch আর detached HEAD) দেখেছেন, tag হলো refs/tags/-এর নিচে থাকা একটি ref — একটি commit-এর স্থায়ী নাম, যা branch-এর মতো নতুন commit-এর সাথে সরে না। Git-এ tag দুই রকম:

উইন্ডো-সিটের commit b6ea870-এ দুই রকম tag-ই দিয়ে পার্থক্য দেখি:

$ git tag tested
$ git tag -a v1.1.0 -m "Release 1.1.0: window seats"
$ git cat-file -t tested
commit
$ git cat-file -t v1.1.0
tag
$ git cat-file -p v1.1.0
object b6ea870de0cc17925ea2b4a80789045caeda0704
type commit
tag v1.1.0
tagger Rahim <rahim@example.com> 1768449900 +0600

Release 1.1.0: window seats
$ git show --stat v1.1.0
tag v1.1.0
Tagger: Rahim <rahim@example.com>
Date:   Thu Jan 15 10:05:00 2026 +0600

Release 1.1.0: window seats

commit b6ea870de0cc17925ea2b4a80789045caeda0704
Author: Rahim <rahim@example.com>
Date:   Thu Jan 15 10:04:00 2026 +0600

    feat(seat): let passengers ask for a window seat
…
 seat.js | 6 ++++++
 1 file changed, 6 insertions(+)

তালিকা, সাজানো, push আর মোছা

পরের কয়েকটি commit আর একটি release candidate (অংশ ৬) tag দেওয়ার পরে তালিকা:

$ git tag
tested
v1.0.0
v1.1.0
v2.0.0-rc.1
$ git tag -n
tested          feat(seat): let passengers ask for a window seat
v1.0.0          Release 1.0.0
v1.1.0          Release 1.1.0: window seats
v2.0.0-rc.1     Release candidate 2.0.0-rc.1
$ git tag -l "v1.*"
v1.0.0
v1.1.0
$ git tag --sort=-v:refname
v2.0.0-rc.1
v1.1.0
v1.0.0
tested

git tag একা অক্ষরের ক্রমে সাজায়। -n annotated tag-এর বার্তা দেখায়; lightweight tested-এর জন্য commit-এর subject. -l একটি glob pattern নেয়। আর --sort=v:refname নামের সংখ্যাগুলোকে সংখ্যা হিসেবে ধরে (version sort), সামনে - দিলে উল্টো ক্রম, নতুনটি ওপরে। কিন্তু সাবধান — Git-এর version sort SemVer নয়। একটি আলাদা পরীক্ষার repository-তে একই commit-এ কয়েকটি tag দিয়ে দেখুন:

$ git tag
v1.10.0
v1.2.0
v1.9.0
v2.0.0
v2.0.0-alpha
v2.0.0-alpha.1
v2.0.0-beta
v2.0.0-rc.1
$ git tag --sort=-v:refname
v2.0.0-rc.1
v2.0.0-beta
v2.0.0-alpha.1
v2.0.0-alpha
v2.0.0
v1.10.0
v1.9.0
v1.2.0
$ git -c versionsort.suffix=- tag --sort=-v:refname
v2.0.0
v2.0.0-rc.1
v2.0.0-beta
v2.0.0-alpha.1
v2.0.0-alpha
v1.10.0
v1.9.0
v1.2.0

Push: git push ডিফল্টে tag পাঠায় না — tag আলাদা করে পাঠাতে হয় (remote-এর বিস্তারিত পর্ব ১৪ — Remote repository). এখানে remote হলো একটি local bare repository ../origin.git:

$ git push origin main
To ../origin.git
 * [new branch]      main -> main
$ git push origin v1.1.0
To ../origin.git
 * [new tag]         v1.1.0 -> v1.1.0
$ git push origin --tags
To ../origin.git
 * [new tag]         tested -> tested
 * [new tag]         v1.0.0 -> v1.0.0
 * [new tag]         v2.0.0-rc.1 -> v2.0.0-rc.1
$ git tag -d tested
Deleted tag 'tested' (was b6ea870)
$ git push origin --delete tested
To ../origin.git
 - [deleted]         tested

৫ · git describe আর tag দিয়ে history পড়া

Tag দেওয়া commit-এর মাঝখানের commit-গুলোর নাম কী? একটি test build-এর গায়ে “9bc3d2d” লেখার চেয়ে “v1.1.0-এর পরে ২টি commit” অনেক বেশি তথ্য দেয়। git describe ঠিক এই নাম বানায়:

# HEAD = b6ea870, exactly at v1.1.0
$ git describe
v1.1.0
# two commits later (a7e0f71, then 9bc3d2d)
$ git describe
v1.1.0-2-g9bc3d2d
$ git describe --tags
v1.1.0-2-g9bc3d2d
$ git tag -a v2.0.0-rc.1 -m "Release candidate 2.0.0-rc.1"
$ git describe
v2.0.0-rc.1
# one more commit (1afe061)
$ git describe
v2.0.0-rc.1-1-g1afe061
$ git describe --long v1.1.0
v1.1.0-0-gb6ea870
$ git describe --abbrev=0 --exclude "*-*" 1afe061
v1.1.0

দুই tag-এর মাঝের commit-এর তালিকা — release notes-এর কাঁচামাল — দেখায় range syntax A..B: B থেকে পৌঁছানো যায় কিন্তু A থেকে নয় এমন commit (পর্ব ৯ — History আর পার্থক্য দেখা)।

$ git log --oneline v1.0.0..v1.1.0
b6ea870 feat(seat): let passengers ask for a window seat
30ee2e5 fix(fare): round fare to whole taka
$ git log --oneline --decorate
1afe061 (HEAD -> main) fix(fare): add the Dhaka-Khulna route
9bc3d2d (tag: v2.0.0-rc.1) test(fare): cover the route table
a7e0f71 feat(fare)!: read fares from a route table
b6ea870 (tag: v1.1.0, tag: tested) feat(seat): let passengers ask for a window seat
30ee2e5 fix(fare): round fare to whole taka
1674d4e (tag: v1.0.0) docs: add README
e6e2912 feat: add fare calculator

১.০.০ থেকে ১.১.০-এ ঠিক দুটি commit: একটি feat, একটি fix. নতুন সুবিধা এসেছে, কিছু ভাঙেনি — তাই MINOR বাড়ানো (১.০.০ → ১.১.০) সঠিক ছিল। এই যুক্তির নিয়মই পরের অংশ।

৬ · Semantic Versioning 2.0.0 — version নম্বর একটি প্রতিশ্রুতি

Semantic Versioning (SemVer) লিখেছিলেন Tom Preston-Werner; ২.০.০ সংস্করণের spec প্রকাশ হয় ২০১৩ সালের দিকে। মূল ধারণা: version নম্বর দেখেই ব্যবহারকারী বুঝবেন হালনাগাদ করলে তাঁর কোড ভাঙবে কি না। এজন্য আগে একটি public API ঘোষণা করতে হয় — documentation-এ লেখা কোন function, command বা format অন্যরা ব্যবহার করবেন। তারপর MAJOR.MINOR.PATCH:

• সংখ্যাগুলো অ-ঋণাত্মক পূর্ণসংখ্যা, সামনে শূন্য নিষেধ: 1.02.0 বৈধ নয়। প্রতিটি অংশ আলাদা সংখ্যা: 1.10.0 > 1.9.0.
• প্রকাশিত version বদলায় না: একই নম্বরে নতুন কিছু প্রকাশ করা যাবে না; ভুল হলে নতুন version.
• 0.y.z = প্রাথমিক উন্নয়ন: যেকোনো সময় যেকোনো কিছু বদলাতে পারে; public API স্থিতিশীল ধরা যাবে না। 1.0.0 থেকে public API সংজ্ঞায়িত, প্রতিশ্রুতি শুরু।
• Pre-release: PATCH-এর পরে - আর ডট দিয়ে ভাগ করা identifier: 1.0.0-alpha.1, 2.0.0-rc.1. Identifier-এ শুধু [0-9A-Za-z-], ফাঁকা নয়, সংখ্যা হলে সামনে শূন্য নয়। Pre-release মানে “এখনো প্রতিশ্রুতি পূর্ণ নয়”; release candidate (rc) মানে “কোনো সমস্যা না পেলে এটিই মূল release হবে”।
• Build metadata: + আর identifier: 1.0.0+build.5, 1.0.0-rc.1+20260115. Precedence-এ পুরো উপেক্ষিত — 1.0.0+build.5 আর 1.0.0 একই অগ্রাধিকারের।
• “v” উপসর্গ: v1.2.3 নিজে semantic version নয়; tag-এর নামে “v” লাগানো একটি প্রচলিত রীতি (SemVer-এর FAQ-ও তাই বলে)। Version হলো 1.2.3.

Precedence — কোন version বড়

Precedence-এর নিয়ম spec-এ ধাপে ধাপে দেওয়া: (১) MAJOR, MINOR, PATCH বাঁ থেকে সংখ্যা হিসেবে তুলনা। (২) এগুলো সমান হলে, pre-release থাকা version ছোট: 1.0.0-rc.1 < 1.0.0. (৩) দুটিতেই pre-release থাকলে identifier বাঁ থেকে একটি একটি করে: দুটিই সংখ্যা হলে সংখ্যা হিসেবে; অক্ষর থাকলে ASCII ক্রমে; সংখ্যা-identifier অক্ষরেরটির চেয়ে ছোট; আর আগের সব সমান হলে যার identifier বেশি, সে বড়। নিচের প্রোগ্রাম spec-এর এই নিয়মগুলো সরাসরি বাস্তবায়ন করে:

// SemVer 2.0.0: parse MAJOR.MINOR.PATCH[-pre][+build] and compare by the spec's precedence rules.
const N = "(0|[1-9]\\d*)", ID = "(?:0|[1-9]\\d*|\\d*[A-Za-z-][0-9A-Za-z-]*)";
const RE = new RegExp(`^${N}\\.${N}\\.${N}(?:-(${ID}(?:\\.${ID})*))?(?:\\+([0-9A-Za-z-]+(?:\\.[0-9A-Za-z-]+)*))?$`);
function parse(v) {
  const m = RE.exec(v);
  if (!m) return null;                       // e.g. leading zeros or a missing part
  return { nums: [+m[1], +m[2], +m[3]], pre: m[4] ? m[4].split(".") : [], build: m[5] || "" };
}
function cmpId(a, b) {                       // compare one pre-release identifier
  const na = /^\d+$/.test(a), nb = /^\d+$/.test(b);
  if (na && nb) return Number(a) - Number(b); // numbers compare as numbers
  if (na !== nb) return na ? -1 : 1;          // numeric identifiers are lower
  return a < b ? -1 : a > b ? 1 : 0;          // otherwise ASCII order
}
function compare(x, y) {
  const a = parse(x), b = parse(y);
  for (let i = 0; i < 3; i++) if (a.nums[i] !== b.nums[i]) return a.nums[i] - b.nums[i];
  if (!a.pre.length || !b.pre.length) return b.pre.length - a.pre.length; // release wins
  for (let i = 0; i < Math.min(a.pre.length, b.pre.length); i++) {
    const c = cmpId(a.pre[i], b.pre[i]);
    if (c) return c;
  }
  return a.pre.length - b.pre.length;         // more identifiers = higher
}
const list = ["1.0.0", "1.10.0", "1.0.0-rc.1", "1.0.0-beta.11", "1.2.0", "1.0.0-alpha",
  "1.0.0-beta", "1.0.0-alpha.beta", "1.0.0-beta.2", "1.0.0-alpha.1", "2.0.0-rc.1"];
console.log("text sort:  " + [...list].sort().join(" "));
console.log("semver sort: " + [...list].sort(compare).join(" < "));
console.log("1.0.0+build.5 vs 1.0.0 ->", compare("1.0.0+build.5", "1.0.0"));
for (const bad of ["1.02.0", "1.0", "1.0.0-01", "v1.0.0"]) console.log(bad, "->", parse(bad));

text sort:  1.0.0 1.0.0-alpha 1.0.0-alpha.1 1.0.0-alpha.beta 1.0.0-beta 1.0.0-beta.11 1.0.0-beta.2 1.0.0-rc.1 1.10.0 1.2.0 2.0.0-rc.1
semver sort: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0 < 1.2.0 < 1.10.0 < 2.0.0-rc.1
1.0.0+build.5 vs 1.0.0 -> 0
1.02.0 -> null
1.0 -> null
1.0.0-01 -> null
v1.0.0 -> null

বিকল্প: Calendar Versioning

সব software-এর “public API” থাকে না। একটি অ্যাপ, একটি website বা একটি operating system-এর ব্যবহারকারী জানতে চান “কবেকার version?” — “কী ভাঙল” নয়। এমন ক্ষেত্রে অনেকে Calendar Versioning (CalVer) ব্যবহার করেন: তারিখভিত্তিক নম্বর। যেমন Ubuntu-র 24.04 মানে ২০২৪ সালের এপ্রিল (YY.MM). calver.org নামের একটি সাইটে প্রচলিত রূপগুলো (YYYY.MM.DD, YY.MINOR ইত্যাদি) সংকলিত আছে। CalVer কোনো একক নির্দিষ্ট spec নয়, একটি রীতি — প্রতিটি project নিজের format ঘোষণা করে। আর দুটি মেশানোও যায়: বছরভিত্তিক MAJOR, বাকিটা SemVer-এর মতো। কোনটি “সঠিক”, তা নিয়ে মতভেদ আছে; প্রশ্নটি হলো আপনার ব্যবহারকারীর কাছে কোন তথ্য বেশি জরুরি (ভাবনার প্রশ্ন ৩)।

৭ · Commit থেকে পরের version

এখন দুই অংশ জোড়া লাগাই। Commit-গুলো Conventional Commits মানলে পরের version যন্ত্র নিজেই হিসাব করতে পারে: শেষ release-এর পরের সব commit দেখুন, প্রতিটির “ধাক্কা” বের করুন, আর সবচেয়ে বড়টি নিন। নিচের stepper-এ আমাদের অ্যাপের শেষ স্থিতিশীল release v1.1.0-এর পরের তিনটি commit:

একই নিয়ম কোডে — Conventional Commits-এর spec feat/fix/breaking-এর অর্থ বাঁধে; perf-কে PATCH ধরা অনেক টুলের প্রচলিত রীতি:

// Next version from Conventional Commit messages (feat -> minor, fix/perf -> patch, breaking -> major).
const HEADER = /^(\w+)(?:\(([^)]*)\))?(!)?: (.+)$/;
function bumpOf(msg) {
  const [first, ...rest] = msg.split("\n");
  const m = HEADER.exec(first);
  if (!m) return 0;                                   // not a Conventional Commit: ignored
  const breaking = m[3] === "!" || rest.some(l => /^BREAKING[ -]CHANGE: /.test(l));
  if (breaking) return 3;
  if (m[1] === "feat") return 2;
  if (m[1] === "fix" || m[1] === "perf") return 1;
  return 0;                                           // docs, test, chore, ci ... no release
}
function next(version, messages) {
  let [major, minor, patch] = version.split(".").map(Number);
  let bump = Math.max(0, ...messages.map(bumpOf));
  if (major === 0 && bump === 3) bump = 2;            // a chosen 0.x rule: breaking -> minor
  if (bump === 3) return `${major + 1}.0.0`;
  if (bump === 2) return `${major}.${minor + 1}.0`;
  if (bump === 1) return `${major}.${minor}.${patch + 1}`;
  return version + " (no release)";
}
const sinceV110 = [
  "feat(fare)!: read fares from a route table\n\nBREAKING CHANGE: fare(km) is now fare(from, to).",
  "test(fare): cover the route table",
  "fix(fare): add the Dhaka-Khulna route",
];
console.log("1.1.0 ->", next("1.1.0", sinceV110));
console.log("1.1.0 ->", next("1.1.0", ["fix(fare): round to taka", "docs: fix typo"]));
console.log("1.1.0 ->", next("1.1.0", ["feat(seat): add window seat", "fix: null seat"]));
console.log("0.4.2 ->", next("0.4.2", ["refactor!: rename pickSeat to chooseSeat"]));
console.log("1.1.0 ->", next("1.1.0", ["docs: add README", "Fixed stuff"]));

1.1.0 -> 2.0.0
1.1.0 -> 1.1.1
1.1.0 -> 1.2.0
0.4.2 -> 0.5.0
1.1.0 -> 1.1.0 (no release)

৮ · Changelog আর release notes

Commit-এর ইতিহাস developer-দের জন্য। ব্যবহারকারী — আরেকজন developer যিনি আপনার library ব্যবহার করেন, বা অ্যাপের মালিক — জানতে চান: “এই version-এ আমার জন্য কী বদলাল, আর হালনাগাদ করলে কী করতে হবে?” এর উত্তর দুই রূপে আসে:

• Changelog: repository-তে একটি ফাইল (সাধারণত CHANGELOG.md), যেখানে প্রতিটি version-এর পরিবর্তন নতুন থেকে পুরোনো ক্রমে জমা হয়।
• Release notes: একটি নির্দিষ্ট release-এর জন্য লেখা ঘোষণা — প্রায়ই changelog-এর অংশ, সাথে হালনাগাদের নির্দেশনা, পরিচিত সমস্যা, ধন্যবাদ। অনেক hosting platform tag-এর সাথে release পাতা বানাতে দেয়।

Changelog-এর একটি জনপ্রিয় রীতি “Keep a Changelog” (keepachangelog.com, Olivier Lacan-এর শুরু করা; আমাদের জানা মতে এর format-এর সর্বশেষ সংস্করণ ১.১.০)। মূল কথা: changelog মানুষের জন্য, যন্ত্রের জন্য নয়; প্রতিটি version-এর শিরোনামে তারিখ (ISO 8601: 2026-01-15); ওপরে একটি [Unreleased] অংশ, যেখানে পরের release-এর পরিবর্তন জমে; আর পরিবর্তনগুলো ছয় দলে: Added, Changed, Deprecated, Removed, Fixed, Security. সবচেয়ে বড় পরামর্শ: “git log-এর কপি changelog নয়” — test, chore, “typo ঠিক” ব্যবহারকারীর কোনো কাজে লাগে না।

Conventional Commits থাকলে changelog-এর খসড়া যন্ত্র বানাতে পারে। নিচের প্রোগ্রাম v1.1.0..v2.0.0-এর চারটি আসল commit আর আরও বেশি দল দেখাতে দুটি কাল্পনিক commit (বানানো hash) নিয়ে Keep a Changelog-ধাঁচের শিরোনামে সাজায়, সবার ওপরে breaking change আলাদা করে:

// Changelog generator: group Conventional Commits by type under Keep a Changelog-style headings.
const commits = [   // newest first: 4 real commits of v1.1.0..v2.0.0 + 2 imagined (made-up hashes)
  ["d23ad56", "docs: add changelog for 2.0.0"],
  ["1afe061", "fix(fare): add the Dhaka-Khulna route"],
  ["9bc3d2d", "test(fare): cover the route table"],
  ["a7e0f71", "feat(fare)!: read fares from a route table\n\nBREAKING CHANGE: fare(km) is now fare(from, to)."],
  ["a1b2c3d", "perf(seat): stop rescanning taken seats"],
  ["9f8e7d6", "feat(seat): show seat numbers on the ticket"],
];
const SECTION = { feat: "Added", fix: "Fixed", perf: "Changed", refactor: "Changed" };
function changelog(version, date, list) {
  const groups = { "BREAKING CHANGES": [], Added: [], Changed: [], Fixed: [] };
  for (const [hash, msg] of list.slice().reverse()) {          // oldest first
    const m = /^(\w+)(?:\(([^)]*)\))?(!)?: (.+)$/.exec(msg.split("\n")[0]);
    if (!m) continue;
    const [, type, scope, bang, desc] = m;
    const note = (/^BREAKING[ -]CHANGE: (.+)$/m.exec(msg) || [])[1];
    const item = `- ${scope ? "**" + scope + ":** " : ""}${desc} (${hash})`;
    if (bang || note) groups["BREAKING CHANGES"].push(`- ${note || desc} (${hash})`);
    if (SECTION[type]) groups[SECTION[type]].push(item);       // docs, test, chore: skipped
  }
  const out = [`## [${version}] - ${date}`];
  for (const [title, items] of Object.entries(groups))
    if (items.length) out.push("", `### ${title}`, ...items);
  return out.join("\n");
}
console.log(changelog("2.0.0", "2026-01-15", commits));

## [2.0.0] - 2026-01-15

### BREAKING CHANGES
- fare(km) is now fare(from, to). (a7e0f71)

### Added
- **seat:** show seat numbers on the ticket (9f8e7d6)
- **fare:** read fares from a route table (a7e0f71)

### Changed
- **seat:** stop rescanning taken seats (a1b2c3d)

### Fixed
- **fare:** add the Dhaka-Khulna route (1afe061)

বাস্তবে এই কাজের জন্য তৈরি টুল আছে। লেখার সময়ে পরিচিত দুটি ধারা: একটি ধরন (semantic-release-এর মতো) CI-তে প্রতিটি merge-এর পরে commit পড়ে version ঠিক করে, tag দেয়, changelog লিখে package প্রকাশ করে — মানুষের হাত ছাড়াই; আরেক ধরন (release-please-এর মতো) পরিবর্তনগুলো জমিয়ে একটি “release pull request” খুলে রাখে, যেখানে প্রস্তাবিত version আর changelog থাকে, আর মানুষ সেটি merge করলে release হয়। কোন টুল, কোন option আর কোন platform — বিস্তারিত বদলায়; প্রতিটির documentation দেখে নিন। নীতি একই: commit message → version → changelog → tag.

৯ · Release process আর deprecation policy

একটি release মানে শুধু একটি tag নয়। ঈদের আগে বাসের টিকিট বিক্রির কথা ভাবুন: কাউন্টার খোলার আগের রাতে ভাড়ার তালিকা চূড়ান্ত হয় (আর বদলানো যায় না), কয়েকজন কর্মী পরীক্ষামূলক টিকিট কেটে দেখেন, তারপর সকালে কাউন্টার খোলে আর বোর্ডে নোটিশ ঝোলে “এবারের ভাড়া, নতুন রুট”। Software release-এর ধাপও এমন। নিচের stepper আমাদের অ্যাপের ২.০.০ release — প্রতিটি Git বার্তা আসল:

$ git commit -m "docs: add changelog for 2.0.0"
[main d23ad56] docs: add changelog for 2.0.0
 1 file changed, 12 insertions(+)
 create mode 100644 CHANGELOG.md
$ git tag -a v2.0.0 -m "Release 2.0.0"
$ git push --follow-tags origin main
To ../origin.git
   1afe061..d23ad56  main -> main
 * [new tag]         v2.0.0 -> v2.0.0
$ git describe
v2.0.0
$ git tag --sort=-v:refname
v2.0.0-rc.1
v2.0.0
v1.1.0
v1.0.0
$ git -c versionsort.suffix=- tag --sort=-v:refname
v2.0.0
v2.0.0-rc.1
v1.1.0
v1.0.0
$ git ls-remote --tags origin
2db868b2a79f3683196bd8a36e9fe1745b43a94a	refs/tags/v1.0.0
1674d4ed4d89b641038fddbc3d7b21bdee028dbf	refs/tags/v1.0.0^{}
…
aa07a6e1c9e98f686d4b50b3f619611f8813dc70	refs/tags/v2.0.0
d23ad56f42ecd90311362bd89ef130f4dbf156b1	refs/tags/v2.0.0^{}
…

Deprecation policy — ভাঙার আগে সতর্ক করা

Deprecation মানে কোনো সুবিধা “এখনো কাজ করে, কিন্তু ভবিষ্যতে সরানো হবে” — এই ঘোষণা। রেলের সময়সূচি বদলানোর আগে স্টেশনে কয়েক সপ্তাহ নোটিশ ঝোলে; হঠাৎ বদলালে যাত্রীরা ট্রেন হারান। SemVer-এর FAQ-এর পরামর্শ: কিছু deprecated করলে documentation হালনাগাদ করুন, deprecation-টি একটি MINOR release-এ দিন, আর সরানোর কাজ পরের MAJOR-এ — যাতে ব্যবহারকারী অন্তত একটি MINOR version-এ সতর্কবার্তা দেখেন। একটি লিখিত policy-তে সাধারণত থাকে:

• কীভাবে জানানো হবে: changelog-এর Deprecated অংশ, documentation, আর চালানোর সময় সতর্কবার্তা (যেমন “fare(km) is deprecated; use fare(from, to)”).
• কতদিন: কমপক্ষে কয়টি MINOR release বা কত মাস পুরোনো রূপ চলবে, আর কোন MAJOR-এ সরানো হবে।
• বিকল্প: প্রতিটি deprecated জিনিসের পাশে নতুন পথ আর হালনাগাদের নির্দেশনা।
• সমর্থনের সময়: পুরোনো MAJOR (যেমন ১.x) কতদিন security fix পাবে। অনেক বড় project “long-term support” (LTS) version ঘোষণা করে।

আমাদের অ্যাপের দল ভুলটি করেছিল: fare(km) সরাসরি ২.০.০-এ সরানো হয়েছে, আগে deprecated না করে। ভালো পথ হতো: ১.২.০-এ fare(from, to) যোগ (MINOR) আর fare(km) deprecated, তারপর ২.০.০-এ সরানো। Web API-র ক্ষেত্রে version আর deprecation-এর আলোচনা System Design কোর্সে — REST API নকশা, আর deploy ও rollout — Deployment আর release.

১০ · AI-এর যুগে — commit message আর release-এ AI-কে যাচাই

অনেক editor আর AI assistant এখন staged diff দেখে commit message লিখে দেয়, changelog বানায়, release command সাজেস্ট করে। সময় বাঁচে, কিন্তু এই বিষয়ে কিছু চেনা ভুল আছে:

AI-এর লেখা commit message বা changelog হাতে পেলে — চেকলিস্ট

• Subject-এর type আর scope diff-এর সাথে মেলে; breaking change থাকলে ! বা BREAKING CHANGE: আছে
• Body-তে “কেন” আছে, আর সেটা সত্যিই আমার জানা কারণ — AI-এর অনুমান নয়
• Issue নম্বর আর trailer-এর নাম/email সঠিক; trailer শেষ অনুচ্ছেদে
• Changelog-এর প্রতিটি লাইন git log-এর একটি আসল commit থেকে এসেছে
• প্রস্তাবিত version নিজে SemVer-এর নিয়মে হিসাব করে মিলিয়েছি
• Tag বা push-এর কোনো command আগে throwaway clone-এ চালিয়েছি; প্রকাশিত tag সরানোর প্রস্তাব বাতিল করেছি