Skip to content

অধ্যায় ১৩: প্যাকেজ ডিস্ট্রিবিউশন এবং ভার্সনিং স্ট্র্যাটেজি

১৩.১ Semantic Versioning (SemVer): প্যাকেজের ভাষা

আপনার প্যাকেজটি যখন হাজার হাজার ডেভেলপার ব্যবহার করবে, তখন আপনার একটি ভুল সিদ্ধান্তের কারণে তাদের প্রোডাকশন সাইট ডাউন হয়ে যেতে পারে। এই বিপর্যয় এড়ানোর জন্য আমরা Semantic Versioning বা SemVer মেনে চলব।

ফরম্যাট: MAJOR.MINOR.PATCH (উদাহরণ: 1.0.2)

১৩.১.১ ভার্সন পরিবর্তনের নিয়ম

  1. MAJOR (1.x -> 2.x): যখন আপনি এমন পরিবর্তন করেছেন যা আগের কোডের সাথে কম্প্যাটিবল নয় (Breaking Changes)।

    উদাহরণ: Invoice::create() মেথডের নাম বদলে Invoice::make() করা হলো। অথবা কনফিগারেশন ফাইলের স্ট্রাকচার আমূল বদলে ফেলা হলো।

  2. MINOR (1.1 -> 1.2): যখন আপনি নতুন ফিচার যুক্ত করেছেন কিন্তু পুরনো কোড ব্রেক করেনি।

    উদাহরণ: ইনভয়েসে নতুন addTax() মেথড যুক্ত করা হয়েছে। পুরনো ইউজাররা আপডেট করলেও সমস্যা নেই।

  3. PATCH (1.0.1 -> 1.0.2): যখন আপনি কোনো বাগ ফিক্স করেছেন।

    উদাহরণ: ইনভয়েস টোটালে দশমিকের ভুল ছিল, সেটি ঠিক করা হয়েছে।

আর্কিটেক্ট নোট: প্যাকেজ ডেভেলপমেন্টে v0.x.x দিয়ে শুরু করা বুদ্ধিমানের কাজ। যতক্ষণ না আপনি ১০০% নিশ্চিত যে API স্টেবল হয়েছে, ততক্ষণ 1.0.0 রিলিজ করবেন না। 0.x ভার্সনে ব্রেকিং চেঞ্জেস আসা গ্রহণযোগ্য।

১৩.২ রিলিজের পূর্বপ্রস্তুতি

পাবলিশ বাটনে চাপ দেওয়ার আগে নিচের চেকলিস্টটি মিলিয়ে নিন। একবার পাবলিশ হয়ে গেলে সেটি ইন্টারনেট থেকে মুছে ফেলা প্রায় অসম্ভব।

১৩.২.১ composer.json ভ্যালিডেশন

আপনার জেসন ফাইলে কোনো সিনট্যাক্স এরর আছে কি না তা চেক করুন।

bash
composer validate

যদি আউটপুট আসে The composer.json is valid, তবে আপনি নিরাপদ।

১৩.২.২ লাইসেন্স এবং রিডমি

LICENSE: ওপেন সোর্স প্যাকেজের জন্য সাধারণত MIT লাইসেন্স ব্যবহার করা হয়। প্যাকেজের রুটে LICENSE নামে ফাইল তৈরি করে টেক্সটটি পেস্ট করুন। এটি ছাড়া বড় কোম্পানি আপনার প্যাকেজ ব্যবহার করবে না।

README.md: এটি আপনার প্যাকেজের মার্কেটিং ফেস। এখানে অবশ্যই থাকতে হবে:

  • ইনস্টলেশন কমান্ড
  • কনফিগারেশন গাইড
  • ব্যাসিক ব্যবহারের উদাহরণ (Code Snippets)

১৩.২.৩ .gitattributes দিয়ে প্যাকেজ স্লিম করা

যখন ইউজার composer require দেয়, তখন সে আপনার প্যাকেজের tests, docs, github actions ফাইলগুলো ডাউনলোড করতে চায় না। এগুলো শুধু আপনার ডেভেলপমেন্টের জন্য। ইউজারের ভেন্ডর ফোল্ডারের জায়গা বাঁচাতে .gitattributes ফাইল ব্যবহার করুন।

ফাইল: .gitattributes (প্যাকেজ রুটে)

plaintext
/tests export-ignore
/docs export-ignore
phpunit.xml export-ignore
.github export-ignore

এর ফলে গিটহাবে ফাইলগুলো থাকবে, কিন্তু কম্পোজার দিয়ে ইন্সটল করলে ইউজারের ফোল্ডারে যাবে না।

১৩.৩ গিট ট্যাগিং এবং রিলিজ

কম্পোজার বা প্যাকাজিস্ট সরাসরি গিট ব্রাঞ্চ (যেমন main বা develop) রিড করে না (যদি না আপনি dev-main রিকোয়ার করেন)। স্টেবল রিলিজের জন্য কম্পোজার Git Tags খোঁজে।

১৩.৩.১ ট্যাগ তৈরি করা

আপনার প্যাকেজের সব কোড কমিট এবং পুশ করার পর, একটি ট্যাগ তৈরি করুন।

bash
# ১. ট্যাগ তৈরি
git tag -a v1.0.0 -m "Initial Release of InvoiceLite"

# ২. ট্যাগ পুশ করা (সাধারণ পুশে ট্যাগ যায় না)
git push origin --tags

এখন গিটহাবে গিয়ে দেখবেন "Releases" সেকশনে v1.0.0 দেখাচ্ছে।

১৩.৪ Packagist.org এ সাবমিশন

Packagist হলো পিএইচপির প্যাকেজগুলোর সেন্ট্রাল রিপোজিটরি। এটি কোনো কোড হোস্ট করে না, এটি শুধু মেটাডাটা এবং গিটহাবের লিংক হোস্ট করে।

ধাপসমূহ:

  1. Packagist.org-এ যান এবং অ্যাকাউন্ট খুলুন (গিটহাব দিয়ে লগইন করাই ভালো)।
  2. ডানদিকের মেনু থেকে "Submit" এ ক্লিক করুন।
  3. আপনার গিটহাব রিপোজিটরির লিংক পেস্ট করুন (যেমন: https://github.com/DevMaster/invoice-lite)।
  4. "Check" বাটনে ক্লিক করুন। প্যাকাজিস্ট আপনার composer.json ভ্যালিডেট করবে।
  5. সব ঠিক থাকলে "Submit" করুন।

অভিনন্দন! এখন বিশ্বের যেকোনো লারাভেল ডেভেলপার নিচের কমান্ড দিয়ে আপনার প্যাকেজ ব্যবহার করতে পারবে:

bash
composer require devmaster/invoicelite

১৩.৫ অটো-আপডেট কনফিগারেশন (Webhooks)

বর্তমানে, আপনি যদি গিটহাবে নতুন ভার্সন v1.0.1 পুশ করেন, প্যাকাজিস্ট সেটি জানবে না যতক্ষণ না আপনি প্যাকাজিস্ট ওয়েবসাইটে গিয়ে ম্যানুয়ালি "Update" বাটনে ক্লিক করেন। এটি অটোমেট করা জরুরি।

সেটআপ:

  1. Packagist ড্যাশবোর্ডে আপনার প্যাকেজ পেজে যান।
  2. GitHub Service Hook এর নির্দেশাবলি দেখুন। আপনাকে একটি API Token দেওয়া হবে।
  3. আপনার গিটহাব রিপোজিটরির Settings > Webhooks > Add webhook-এ যান।
  4. Payload URL: https://packagist.org/api/github/oauth/hook (ডকুমেন্টেশন অনুযায়ী)।
  5. Secret: প্যাকাজিস্টের টোকেন।
  6. Content type: application/json

এখন গিটহাবে পুশ করলেই প্যাকাজিস্ট অটোমেটিক আপডেট হয়ে যাবে।

১৩.৬ প্রাইভেট প্যাকেজ ডিস্ট্রিবিউশন (এন্টারপ্রাইজ সলিউশন)

সব প্যাকেজ ওপেন সোর্স হয় না। ধরুন, আপনি আপনার ক্লায়েন্টের জন্য একটি সিক্রেট পেমেন্ট লজিক প্যাকেজ বানিয়েছেন। এটি প্যাকাজিস্টে দেওয়া যাবে না। তাহলে ক্লায়েন্ট এটি ইন্সটল করবে কীভাবে?

অপশন ১: VCS রিপোজিটরি (সহজ সমাধান)

ক্লায়েন্টের প্রজেক্টের composer.json-এ রিপোজিটরি লিংক সরাসরি বলে দেওয়া যায়।

json
"repositories": [
    {
        "type": "vcs",
        "url": "https://github.com/DevMaster/secret-package"
    }
],
"require": {
    "devmaster/secret-package": "^1.0"
}

শর্ত: ক্লায়েন্টের সার্ভারে বা মেশিনে ওই প্রাইভেট রিপোজিটরিতে এক্সেস (SSH Key) থাকতে হবে।

অপশন ২: Private Packagist / Satis

যদি অনেকগুলো প্রাইভেট প্যাকেজ থাকে, তবে Satis (ফ্রি) বা Private Packagist (পেইড) ব্যবহার করা হয়। এগুলো আপনার নিজস্ব প্যাকাজিস্ত সার্ভার হিসেবে কাজ করে।

১৩.৭ প্যাকেজ মেইনটেনেন্স এবং ডিপ্রিকেশন

প্যাকেজ রিলিজ করার পর আসল কাজ শুরু হয়।

Deprecation Strategy

যদি আপনি Invoice::create মেথডটি বাদ দিতে চান, তবে হুট করে ডিলিট করবেন না।

  1. মেথডটিতে @deprecated ট্যাগ লাগান।
  2. মেথডের ভেতরে trigger_error দিয়ে ওয়ার্নিং দিন।
php
/**
 * @deprecated Use Invoice::make() instead. Will be removed in v2.0.
 */
public static function create($data) {
    trigger_error('Method ' . __METHOD__ . ' is deprecated', E_USER_DEPRECATED);
    return self::make($data);
}
  1. পরবর্তী মেজর ভার্সনে (v2.0) মেথডটি মুছে ফেলুন।

সৎ ক্রেডিট: লেখক AI, সম্পাদক আবুল হাসান