প্রকাশনাসমূহ

• 1: কুবারনেটিস ডাউনলোড করুন
• 2: কুবারনেটিস রিলিজ সাইকেল
• 3: প্যাচ রিলিজ
• 4: ভার্সন Skew পলিসি
• 5: নোটস
• 6: রিলিজ ম্যানেজারস

1 - কুবারনেটিস ডাউনলোড করুন

কুবারনেটিস প্রতিটি উপাদানের জন্য বাইনারি পাঠায় সেইসাথে একটি ক্লাস্টারের সাথে বুটস্ট্র্যাপ বা ইন্টারঅ্যাক্ট (interact) করার জন্য ক্লায়েন্ট অ্যাপ্লিকেশনগুলোর একটি আদর্শ সেটও পাঠায়। এপিআই সার্ভারের মতো উপাদানগুলো একটি ক্লাস্টারের ভিতরে কন্টেইনার ইমেজগুলোর মধ্যে চলতে সক্ষম। সেই উপাদানগুলো অফিসিয়াল রিলিজ প্রক্রিয়ার অংশ হিসাবে কন্টেইনার ইমেজেও পাঠানো হয়। সমস্ত বাইনারি এবং সেইসাথে কন্টেইনার ইমেজ একাধিক অপারেটিং সিস্টেমের পাশাপাশি একাধিক হার্ডওয়্যার আর্কিটেকচারের জন্য উপলব্ধ (available)।

kubectl

কুবারনেটিস কমান্ড-লাইন টুল, kubectl, আপনাকে কুবারনেটিস ক্লাস্টারগুলোর বিপরীতে কমান্ড চালানোর অনুমতি দেয়।

আপনি অ্যাপ্লিকেশন স্থাপন(deploy) করতে, ক্লাস্টার রিসোর্স পরিদর্শন ও পরিচালনা করতে এবং লগ দেখতে kubectl ব্যবহার করতে পারেন। kubectl অপারেশনগুলোর একটি সম্পূর্ণ তালিকা সহ আরও তথ্যের জন্য, kubectl রেফারেন্স ডকুমেন্টেশন দেখুন।

kubectl বিভিন্ন লিনাক্স প্ল্যাটফর্ম, ম্যাকওস এবং উইন্ডোজে ইনস্টলযোগ্য। নীচে আপনার পছন্দের অপারেটিং সিস্টেম খুঁজুন।

• লিনাক্সে kubectl ইনস্টল করুন
• macOS এ kubectl ইনস্টল করুন
• উইন্ডোজে kubectl ইনস্টল করুন

কন্টেইনার ইমেজ

সমস্ত কুবারনেটিস কন্টেইনার ছবি registry.k8s.io কন্টেইনার ইমেজ রেজিস্ট্রিতে স্থাপন করা হয় ।

কন্টেইনার ইমেজ আর্কিটেকচার

সমস্ত কন্টেইনার ইমেজ একাধিক আর্কিটেকচারের জন্য উপলব্ধ, যেখানে কন্টেইনার রানটাইম অন্তর্নিহিত প্ল্যাটফর্মের উপর ভিত্তি করে সঠিকটি বেছে নেওয়া উচিত। কন্টেইনার ইমেজ নামের প্রত্যয়যোগ একটি ডেডিকেটেড আর্কিটেকচারও নেওয়া সম্ভব, উদাহরণস্বরূপ registry.k8s.io/kube-apiserver-arm64:v1.32.0।

কন্টেইনার ইমেজ স্বাক্ষর

কুবারনেটিস 1.32 এর জন্য, কন্টেইনার ইমেজগুলো sigstore স্বাক্ষর ব্যবহার করে স্বাক্ষরিত হয়:

কুবারনেটিস প্রজেক্ট SPDX 2.3 ফরম্যাটে স্বাক্ষরিত কুবারনেটিস কন্টেইনার ইমেজের একটি তালিকা প্রকাশ করে। আপনি এই তালিকাটি আনতে ব্যবহার করতে পারেন:

curl -Ls "https://sbom.k8s.io/$(curl -Ls https://dl.k8s.io/release/stable.txt)/release" | grep "SPDXID: SPDXRef-Package-registry.k8s.io" |  grep -v sha256 | cut -d- -f3- | sed 's/-/\//' | sed 's/-v1/:v1/'

কুবারনেটিস মূল উপাদানগুলোর স্বাক্ষরিত কন্টেইনার ইমেজগুলো ম্যানুয়ালি যাচাই করতে, স্বাক্ষরিত কন্টেইনার ইমেজগুলো যাচাই করুন।

আপনি যদি একটি নির্দিষ্ট আর্কিটেকচারের জন্য একটি কন্টেইনার ইমেজ নেন, তাহলে একক-আর্কিটেকচার ইমেজটি মাল্টি-আর্কিটেকচার ম্যানিফেস্ট তালিকার মতোই সাইন ইন করা হয়।

বাইনারি

2 - কুবারনেটিস রিলিজ সাইকেল

মাইলস্টোন রিলিজের জন্য টার্গেটিং এনহ্যান্সমেন্টস, ইস্যু এবং PR

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

• TL;DR
  • নরমাল ডেভ (সপ্তাহ ১-১১)
  • কোড ফ্রিজ (সপ্তাহ ১২-১৪)
  • পোস্ট-রিলিজ (সপ্তাহ ১৪+)
• সংজ্ঞা
• রিলিজ সাইকেল
• মাইলস্টোন থেকে আইটেম অপসারণ
• মাইলস্টোনে একটি আইটেম সংযোজন
  • মাইলস্টোন রক্ষণাবেক্ষণকারী
  • ফিচার সংযোজন
  • ইস্যু সংযোজন
  • PR সংযোজন
• অন্যান্য প্রয়োজনীয় লেবেল
  • SIG ওনার লেবেল
  • প্রাইওরিটি লেবেল
  • ইস্যু/PR লেবেল

একটি Kubernetes রিলিজে বর্ধিতকরণ, সমস্যা, এবং পুল অনুরোধের শেফারডিং(shepherding) প্রক্রিয়া একাধিক স্টেকহোল্ডারকে বিস্তৃত করে:

• এনহ্যান্সমেন্টস, ইস্যু, এবং পুল রিকুয়েস্ট ওনার
• SIG লিডারশিপ
• রিলিজ টিম

ওয়ার্কফ্লো এবং ইন্টারেকশন সম্পর্কিত তথ্য নীচে বর্ণিত হয়েছে।

একটি এনহ্যান্সমেন্ট, ইস্যু, অথবা পুল রিকুয়েস্ট (PR) এর ওনার হিসেবে, এটি আপনার দায়িত্ব রিলিজ মাইলস্টোন রিকোয়ারমেন্ট পূরণ হয়েছে নিশ্চিত করা। অটোমেশন এবং রিলিজ টিম আপনার সাথে যোগাযোগ করবে যদি আপডেট প্রয়োজন হয়, কিন্তু নিষ্ক্রিয়তার ফলে আপনার কাজ মাইলস্টোন থেকে সরে যেতে পারে। অতিরিক্ত রিকোয়ারমেন্ট প্রয়োজন যখন লক্ষ্য মাইলস্টোন একটি পূর্ববর্তী রিলিজ (আরও তথ্যের জন্য চেরি পিক প্রোসেস দেখ)

TL;DR

আপনি যদি আপনার PR মার্জ করাতে চান তার জন্য নিম্নলিখিত প্রয়োজনীয় লেবেল এবং মাইলস্টোনগুলো প্রয়োজন, এখানে Prow /commands দ্বারা প্রতিনিধিত্ব করা হয়েছে যেগুলি যোগ করা লাগবে:

নরমাল ডেভ (সপ্তাহ ১-১১)

• /sig {name}
• /kind {type}
• /lgtm
• /approved

কোড ফ্রিজ (সপ্তাহ ১২-১৪)

• /milestone {v1.y}
• /sig {name}
• /kind {bug, failing-test}
• /lgtm
• /approved

পোস্ট-রিলিজ (সপ্তাহ ১৪+)

'নরমাল ডেভ' পর্যায়ের ফিরে যাওয়ার রিকোয়ারমেন্ট:

• /sig {name}
• /kind {type}
• /lgtm
• /approved

1.y ব্রাঞ্চে মার্জ করা এখন চেরি পিক্সের মাধ্যমে, রিলিজ ম্যানেজার দ্বারা অনুমোদিত।

পূর্বে, মাইলস্টোন-লক্ষ্যযুক্ত পুল রিকুয়েস্টের জন্য একটি সংস্থায়িত গিটহাব ইস্যু খোলা প্রয়োজন ছিল, কিন্তু এটি আর প্রয়োজন নয় ফিচার বা এনহ্যান্সমেন্ট হলো ইফেক্টিভ গিটহাব ইস্যু বা KEPs যা পরবর্তী পুল রিকুয়েস্টের পথে পরিচালিত হয়।

সাধারণ লেবেলিং প্রক্রিয়াটি আর্টিফ্যাক্ট টাইপ জুড়ে সামঞ্জস্যপূর্ণ হওয়া উচিত।

সংজ্ঞা

• ইস্যু ওনার: সৃষ্টিকারক, অ্যাসাইনিজ, এবং ইস্যুটি রিলিজ মাইলস্টোনে সরবরাহ করা ব্যবহারকারী।

• রিলিজ টিম: প্রতিটি Kubernetes রিলিজে একটি দল আছে যারা বর্ণিত প্রজেক্ট ম্যানেজমেন্টের কাজ করে এখানে।

  যে কোনো প্রদত্ত রিলিজের সাথে সংশ্লিষ্ট দলের যোগাযোগের তথ্য পাওয়া যাবে এখানে.

• Y days: বিজনেস ডে বুঝায়।

• এনহ্যান্সমেন্ট: দেখ "আমার কাজটা কী এনহ্যান্সমেন্ট?"

• এনহ্যান্সমেন্ট ফ্রিজ: সময়সীমা যার মধ্যে KEPs সম্পন্ন করতে হবে এনহ্যান্সমেন্টগুলো বর্তমান রিলিজের অংশ করার জন্য

• এক্সেপশন রিকোয়েস্ট: কোন এনহ্যান্সমেন্ট এর জন্য সময়সীমা বাড়ানোর অনুরোধ করার প্রক্রিয়া

• কোড ফ্রিজ: চূড়ান্ত প্রকাশের তারিখের আগে ~4 সপ্তাহের সময়কাল, যে সময়ে শুধুমাত্র ক্রিটিকাল বাগ ফিক্স রিলিজে মার্জ করা হয়েছে।

• Pruning: একটি রিলিজ মাইলস্টোন থেকে একটি এনহ্যান্সমেন্ট অপসারণের প্রক্রিয়া যদি এটি সম্পূর্ণরূপে বাস্তবায়িত বা অন্যথায় স্থিতিশীল নয় বলে মনে করা হয়।

• রিলিজ মাইলস্টোন: সিমেনটিক ভার্সন স্ট্রিং বা GitHub milestone যা একটি রিলিজ ভার্সন MAJOR.MINOR vX.Y নির্দেশ করে।

  আরও দেখ রিলিজ ভার্সনিং.

• রিলিজ ব্রাঞ্চ: Git ব্রাঞ্চ release-X.Y তৈরি করা হয়েছে vX.Y মাইলস্টোনের জন্য।

  vX.Y-rc.0 রিলিজের সময় তৈরি করা হয়েছে এবং রিলিজের পর প্রায় ১২ মাস ধরে vX.Y.Z প্যাচ রিলিজের সাথে রক্ষণাবেক্ষণ করা হয়েছে।

  দ্রষ্টব্য: রিলিজ 1.19 এবং পরবর্তী ভার্সন 1 বছরের প্যাচ রিলিজ সাপোর্ট পায়, এবং রিলিজ 1.18 এবং তার আগে 9 মাসের প্যাচ রিলিজ সাপোর্ট পেয়েছে।

রিলিজ সাইকেল

কুবারনেটিস রিলিজ বর্তমানে প্রতি বছর প্রায় তিনবার হয়।

রিলিজ প্রক্রিয়াটিকে তিনটি প্রধান পর্যায় হিসাবে বিবেচনা করা যেতে পারে:

• এনহ্যান্সমেন্ট ডেফিনেশন
• ইমপ্লিমেন্টেশন
• স্ট্যাবিলাইজেশন

কিন্তু বাস্তবে, এটি একটি ওপেন সোর্স এবং অ্যাজাইল(agile) প্রকল্প, ফিচার পরিকল্পনা এবং বাস্তবায়ন সব সময়ে ঘটছে। প্রজেক্ট স্কেল এবং বিশ্বব্যাপী ডিস্ট্রিবিউটেড ডেভেলপার বেস এর ফলে, এটি গুরুত্বপূর্ণ যে প্রজেক্টের গতি যেনো ট্রেইলিং স্টেবিলাইজেশন ফেজ এর উপর নির্ভর না করে এবং বরং ক্রমাগত ইন্টিগ্রেশন টেস্টিং চলমান থাকে যা নিশ্চিত করে যে প্রকল্পটি সর্বদা স্থিতিশীল যাতে একজন ডেভেলপার কোন নির্দিষ্ট কমিটে কোন সমস্যা তৈরি করেছে তা চিহ্নিত করা যেতে পারে।

বছর ধরে চলমান ফিচার নির্ধারণের সাথে, কিছু আইটেম একটি নির্দিষ্ট রিলিজের লক্ষ্য হিসেবে উঠে আসবে। এনহ্যান্সমেন্ট ফ্রিজ রিলিজ সাইকেলের ~৪ সপ্তাহের মধ্যে শুরু হয়। এই মুহুর্তে সমস্ত উদ্দেশ্যমূলক ফিচার কাজকে রিলিজ টিমের সাথে একযোগে এনহ্যান্সমেন্ট লিড প্রদত্ত রিলিজ উপযুক্ত পরিকল্পনা নিদর্শনে সংজ্ঞায়িত করা হয়েছে ।

এনহ্যান্সমেন্ট ফ্রিজের পরে, PR এবং ইস্যুগুলোর মাইলস্টোন ট্র্যাক করা গুরুত্বপূর্ণ। মাইলস্টোন থাকা আইটেমগুলি সম্পূর্ণ করার জন্য একটি পাঞ্চডাউন তালিকা হিসাবে ব্যবহৃত হয় রিলিজের জন্য। ইস্যুতে, মাইলস্টোন অবশ্যই সঠিকভাবে প্রয়োগ করতে হবে, triage মাধ্যমে SIG, যাতে রিলিজ টিম বাগ এবং এনহ্যান্সমন্ট ট্র্যাক করতে পারে (যেকোন এনহ্যান্সমেন্ট-সম্পর্কিত ইস্যুর একটি মাইলস্টোন প্রয়োজন)।

PR এ স্বয়ংক্রিয়ভাবে মাইলফলক বরাদ্দ করতে সাহায্য করার জন্য কিছু অটোমেশন রয়েছে৷

এই অটোমেশনটি বর্তমানে নিম্নলিখিত রিপোতে প্রযোজ্য:

• kubernetes/enhancements
• kubernetes/kubernetes
• kubernetes/release
• kubernetes/sig-release
• kubernetes/test-infra

তৈরি করার সময়, master ব্রাঞ্চের বিপরীতে PR গুলোর মানুষের দেওয়া নির্দেশনা প্রয়োজন কোন মাইলস্টোন টার্গেট করতে হবে তার জন্য। একবার মার্জ হলে, master ব্রাঞ্চের বিপরীতে তৈরি করা PR গুলোয় মাইলস্টোন় স্বয়ংক্রিয়ভাবে প্রয়োগ করা হয় তাই সেই সময় থেকে ওই PR এর মাইলস্টোনে মানুষের ব্যবস্থাপনা কম প্রয়োজনীয়। রিলিজ ব্রাঞ্চ এর বিপরীতে তৈরি PR এ, মাইলস্টোন সংক্রিয়ভাবে প্রয়োগ হয় তাই মানুষবিহীন ব্যবস্থাপনা মাইলস্টোনের জন্য সবসময় প্রয়োজন।

অন্য কোনো প্রচেষ্টা যা রিলিজ টিমের দ্বারা ট্র্যাক করা উচিত যা কোনো অটোমেশন আম্ব্রেলার অধীনে নেই তাতে একটি মাইলফলক প্রয়োগ করা উচিত।

ইমপ্লিমেন্টেশন এবং বাগ ফিক্সিং পুরো সাইকেল জুড়ে চলেছে, কিন্তু শেষ হয় কোড-ফ্রিজ সময়কালে।

কোড ফ্রিজ শুরু হয় ~১২ সপ্তাহে এবং পরবর্তী ~২ সপ্তাহ পর্যন্ত চলে। এই সময়ে রিলিজ কোডবেসে শুধুমাত্র গুরুত্বপূর্ণ বাগ ফিক্স গ্রহণ করা হয়।

Code Freeze এর পরে এবং রিলিজের পূর্বে প্রায় দুই সপ্তাহের সময় রয়েছে, যা রিলিজ পূর্বে সমস্ত অবশিষ্ট গুরুত্বপূর্ণ সমস্যাগুলি সমাধান করা আবশ্যক। এটি ডকুমেন্টেশন চূড়ান্ত করার জন্য সময় দেয়।

যখন কোড বেস স্টেবল হয়, তখন মাস্টার ব্রাঞ্চটি সাধারণ উন্নতির জন্য পুনরায় খোলা হয় এবং পরবর্তী রিলিজের মাইলস্টোনে কাজ সেখানে শুরু করা হয়। বর্তমান রিলিজের জন্য অবশিষ্ট যেকোনো সংশোধন মাস্টার থেকে রিলিজ ব্রাঞ্চে চেরি-পিক করা হয়। রিলিজ ব্রাঞ্চ থেকে রিলিজ তৈরি করা হয়।

প্রত্যেকটি রিলিজ একটি বৃহৎ কুবারনেটিস লাইফসাইকের অংশ:

মাইলস্টোন থেকে আইটেম অপসারণ

মাইলস্টোন আইটেম যোগ করার প্রক্রিযার অধিক দূরে যাওয়ার আগে, দয়া করে লক্ষ্য করুন:

রিলিজ টিম এর সদস্যরা মাইলস্টোন থেকে ইস্যু সরাতে পারে যদি তারা অথবা যদি দায়িত্বশীল SIG মনে করে যে সমস্যাটি বাস্তবে রিলিজ ব্লক করছে না এবং সম্ভবত সময়ের মধ্যে সমাধান হবে না।

রিলিজ দলের সদস্যরা নিম্নলিখিত কারণে অথবা এর সমান কারণে মাইলস্টোন থেকে PR-গুলি সরাতে পারেন:

• PR সম্ভবত অস্থিতিশীল এবং ব্লকিং সমস্যা সমাধানের প্রয়োজন নেই
• নতুন PR, লেট ফিচার PR এবং এনহ্যান্সমেন্ট প্রক্রিয়ার অথবা এক্সেপশন প্রক্রিয়া এর মধ্যে যায় নি
• পিআর এর মালিকানা নিতে এবং এটির সাথে কোন ফলো-আপ সমস্যা সমাধান করতে ইচ্ছুক কোন দায়িত্বশীল SIG নেই
• PR সঠিকভাবে লেবেল করা হয় না
• PR-এ কাজ দৃশ্যত থেমে গেছে এবং ডেলিভারির তারিখ অনিশ্চিত বা দেরি হবে

রিলিজ টিমের সদস্যরা লেবেলিং এবং SIG দের সাথে যোগাযোগে সাহায্য করবে,PR কে শ্রেণীবদ্ধ করা জমাদানকারীর দায়িত্ব এবং প্রাসঙ্গিক SIG হতে সাহায্য নিশ্চিত করা যেনো PR দ্বারা কোনো ব্রেক হলে ধ্রুত সমাধানের গ্যারেন্টি দেওয়া হবে।

যেখানে অতিরিক্ত পদক্ষেপ প্রয়োজন, রিলিজ দল নিম্নলিখিত চ্যানেলের মাধ্যমে মানুষ থেকে মানুষে এস্ক্যালেশনের চেষ্টা করবে:

• ইস্যু প্রকারের উপযুক্ত SIG দল এবং SIG সদস্যদের উল্লিখিত করে GitHub-এ মন্তব্য করুন।
• SIG মেইলিং লিস্টে ইমেইল পাঠানো
  • কমিউনিটি সিগ লিস্ট থেকে গ্রুপ ইমেল ঠিকানা দিয়ে বুটস্ট্র্যাপ করা হয়েছে
  • ঐচ্ছিকভাবে সরাসরি SIG নেতৃত্ব বা অন্যান্য SIG সদস্যদের সম্বোধন করে
• SIG এর স্ল্যাক চ্যানেলে বার্তা পাঠানো।
  • কমিউনিটি সিগ লিস্ট থেকে স্ল্যাকচ্যানেল এবং SIG নেতৃত্বের সাথে বুটস্ট্র্যাপ করা হয়েছে
  • ঐচ্ছিকভাবে সরাসরি "@" হ্যান্ডেল দ্বারা SIG নেতৃত্ব বা অন্যদের উল্লেখ করে

মাইলস্টোনে একটি আইটেম সংযোজন

মাইলস্টোন রক্ষণাবেক্ষণকারী

milestone-maintainers এর সদস্যদের GitHub টিম দ্বারা GitHub আর্টিফ্যাক্টগুলিতে রিলিজ মাইলস্টোন নির্দিষ্ট করার দায়িত্ব দেওয়া হয়েছে।

এই গ্রুপটি SIG রিলিজের দ্বারা রক্ষণাবেক্ষণ করা হয়েছে এবং বিভিন্ন SIG-এর নেতৃত্বের প্রতিনিধিত্ব রয়েছে।

ফিচার সংযোজন

ফিচার পরিকল্পনা এবং সংজ্ঞা আজ অনেক রূপ নেয়, কিন্তু একটি সাধারণ উদাহরণ হতে পারে একটি KEP-এ বর্ণিত কাজের একটি বড় অংশ, GitHub-এ সংশ্লিষ্ট টাস্ক সমস্যা সহ। যখন পরিকল্পনাটি একটি বাস্তবায়নযোগ্য অবস্থায় পৌঁছেছে এবং কাজ চলছে, তখন বর্ধন বা এর অংশগুলিকে GitHub সমস্যা তৈরি করে এবং Prow "/milestone" কমান্ড দিয়ে চিহ্নিত করে একটি আসন্ন মাইলফলকের জন্য লক্ষ্য করা হয়।

রিলিজ চক্রের প্রথম ~4 সপ্তাহের জন্য, রিলিজ টিমের এনহ্যান্সমেন্ট লিড সমস্ত প্রয়োজনীয় পরিকল্পনা নিদর্শনগুলি ক্যাপচার করতে GitHub, Slack এবং SIG মিটিংয়ের মাধ্যমে SIG এবং ফিচার মালিকদের সাথে যোগাযোগ করবে।

আপনার যদি আসন্ন রিলিজের মাইলস্টোন লক্ষ্য করার জন্য একটি এনহ্যান্সমেন্ট থাকে, তাহলে আপনার SIG নেতৃত্বের সাথে এবং সেই রিলিজের এনহ্যান্সমেন্ট লিডের সাথে কথা বলুন।

ইস্যু সংযোজন

ইস্যুগুলোকে Prow "/milestone" কমান্ডের মাধ্যমে একটি মাইলস্টোন লক্ষ্য করে চিহ্নিত করা হয়েছে৷

রিলিজ টিমের বাগ Triage লিড এবং সামগ্রিক কমিউনিটি আগত সমস্যাগুলি দেখে এবং সেগুলিকে Triage করে ইস্যু Triage. এর অবদানকারী নির্দেশিকা বিভাগে বর্ণিত হয়েছে।

মাইলস্টোনের সাথে সমস্যাগুলি চিহ্নিত করা কমিউনিটি একটি সমস্যা কখন পর্যবেক্ষণ করা হয়েছিল এবং কখন কমিউনিটি মনে করে এটির সমাধান করা উচিত সে সম্পর্কে আরও ভাল দৃশ্যমানতা প্রদান করে। কোড ফ্রিজ চলাকালীন, একটি PR মার্জ করার জন্য একটি মাইলফলক সেট করতে হবে৷

PR-এর জন্য ওপেন ইস্যুর আর প্রয়োজন নেই, কিন্তু ওপেন ইস্যু এবং সংশ্লিষ্ট PR-এর সিঙ্ক্রোনাইজড লেবেল থাকা উচিত। উদাহরণস্বরূপ, একটি উচ্চ অগ্রাধিকারের বাগ ইস্যু এর সাথে যুক্ত PR মার্জ নাও হতে পারে যদি PR শুধুমাত্র নিম্ন অগ্রাধিকার হিসাবে চিহ্নিত করা হয়।

PR সংযোজন

PR গুলোকে Prow "/milestone" কমান্ডের মাধ্যমে একটি মাইলফলককে লক্ষ্য করে চিহ্নিত করা হয়েছে।

উপরে বর্ণিত কোড ফ্রিজের সময় এটি একটি ব্লকিং প্রয়োজনীয়তা।

অন্যান্য প্রয়োজনীয় লেবেল

এখানে লেবেল এবং তাদের ব্যবহার এবং উদ্দেশ্য তালিকা আছে।

SIG ওনার লেবেল

SIG মালিকের লেবেল SIG কে সংজ্ঞায়িত করে যার দিকে আমরা অগ্রসর হই যদি একটি মাইলস্টোন সমস্যা স্থবির হয় বা অতিরিক্ত মনোযোগের প্রয়োজন হয়। যদি বৃদ্ধির পরে কোন আপডেট না থাকে, তাহলে সমস্যাটি মাইলফলক থেকে স্বয়ংক্রিয়ভাবে সরানো হতে পারে।

এগুলি Prow "/sig" কমান্ডের সাথে যোগ করা হয়। যেমন SIG স্টোরেজ দায়ী লেবেল যোগ করতে, /sig storage দিয়ে মন্তব্য করুন।

প্রাইওরিটি লেবেল

অগ্রাধিকার লেবেলগুলি ইস্যুগুলির রিলিস মাইলস্টোন থেকে বের হতে প্রারম্ভিক এস্ক্যালেশন পথ নির্ধারণে ব্যবহৃত হয়। তারা এটা নির্ধারণ করতে ব্যবহৃত হয় যে ইস্যুর সমাধানের উপরে রিলিস ব্লক করা উচিত কি না।

• priority/critical-urgent: কখনই স্বয়ংক্রিয়ভাবে রিলিজ মাইলস্টোন থেকে সরে যাবেন না; সব উপলভ্য চ্যানেলের মাধ্যমে ক্রমাগত অবদানকারী এবং SIG-এর কাছে এগিয়ে যান।
  • একটি রিলিজ ব্লকিং সমস্যা হিসাবে বিবেচিত।
  • কোড ফ্রিজ চলাকালীন ইস্যু মালিকদের কাছ থেকে দৈনিক আপডেটের প্রয়োজন।
  • একটি প্যাচ রিলিজ প্রয়োজন হবে যদি অনাবিষ্কৃত কিছু মাইনর রিলিজের পর থেকে যায়।
• priority/important-soon: ইস্যু মালিক এবং SIG মালিকের কাছে এগিয়ে যান; বেশ কয়েকটি অসফল বৃদ্ধি প্রচেষ্টার পরে মাইলফলক থেকে সরে যান।
  • একটি রিলিজ ব্লকিং সমস্যা হিসাবে বিবেচনা করা হয় না
  • একটি প্যাচ রিলিজ প্রয়োজন হবে না
  • 4 দিনের গ্রেস পিরিয়ডের পরে কোড ফ্রিজে স্বয়ংক্রিয়ভাবে রিলিজের মাইলফলক থেকে সরে যাবে
• priority/important-longterm: ইস্যু মালিকদের কাছে এগিয়ে যান; 1 বার প্রচেষ্টার পরে মাইলফলক থেকে সরে যান।
  • এমনকি priority/important-soon এর চেয়ে কম জরুরি/সমালোচনা
  • priority/important-soon এর চেয়ে বেশি আক্রমনাত্মকভাবে মাইলফলক থেকে সরে গেছে

ইস্যু/PR লেবেল

ইস্যুর ধরন ব্যবহার করা হয় সময়ের সাথে রিলিজের বিভিন্ন পরিবর্তন সনাক্ত করার জন্য। যা রিলিজ টিমকে ভালো ধারণা দেয় একটি দ্রুত রিলিজ কেডেন্সে কোন ইস্যু গুলো হারিয়ে যাচ্ছে তা সম্পর্কে।

রিলিজ টার্গেট করা সমস্যাগুলির জন্য, পুল অনুরোধ সহ, নিম্নলিখিত একটি সমস্যা ধরনের লেবেল সেট করা আবশ্যক:

• kind/api-change: একটি API যোগ করে, অপসারণ করে বা পরিবর্তন করে।
• kind/bug: একটি নতুন আবিষ্কৃত বাগ সংশোধন করে।
• kind/cleanup: টেস্ট যোগ করা, রিফ্যাক্টরিং, পুরানো বাগ ঠিক করা।
• kind/design: ডিজাইনের সাথে সম্পর্কিত।
• kind/documentation: ডকুমেন্টেশন যোগ করে।
• kind/failing-test: CI টেস্ট কেস ধারাবাহিকভাবে ব্যর্থ হয়।
• kind/feature: নতুন ফিচার।
• kind/flake: CI টেস্ট কেস মাঝে মাঝে ব্যর্থতা দেখাচ্ছে।

3 - প্যাচ রিলিজ

কুবারনেটিস প্যাচ রিলিজের সময়সূচি এবং দলের যোগাযোগ তথ্য।

কুবারনেটিস রিলিজ সাইকেলের সাধারণ তথ্যের জন্য, রিলিজ প্রক্রিয়া বর্ণনা দেখুন।

ক্যাডেন্স(Cadence)

আমাদের সাধারণ প্যাচ রিলিজ ক্যাডেন্সের মাসিক। এটা সাধারণত একটু দ্রুত (1 থেকে 2 সপ্তাহ) হলেও, যখন একটি 1.X মাইনর রিলিজের পরে প্যাচ রিলিজের প্রথমটি হয়। গুরুত্বপূর্ণ বাগ সংশোধন আরও সাধারণ ক্যাডেন্সের বাইরে একটি আগামী রিলিজ সৃষ্টি করতে পারে। আমরা এছাড়াও লক্ষ্য করি যে প্রধান ছুটির সময়ে রিলিজ করা হবে না।

যোগাযোগ

প্যাচ রিলিজ দলের সম্পূর্ণ যোগাযোগের বিস্তারিত তথ্যের জন্য রিলিজ ম্যানেজার পৃষ্ঠা দেখুন।

দয়া করে আমাদেরকে একটি কার্য দিন দিন - আমরা ভিন্ন টাইমজোন অনুযায়ী থাকতে পারি!

রিলিজের মধ্যে দলটি প্রতি সপ্তাহের ভিতরে আসা চেরি পিক অনুরোধগুলি দেখছে। দলটি চেরি পিক অনুরোধকারীদের সাথে GitHub PR, SIG চ্যানেল (স্ল্যাকে) এবং স্ল্যাকের email মাধ্যমে যোগাযোগ করবে, এবং যদি পিআরে কোনো প্রশ্ন থাকে।

চেরি পিক

চেরি পিক প্রসেস অনুসরণ করুন।

চেরি পিক গুলির জন্য গিটহাবে পার্শ্ববর্তী লেবেলসহ (উদাহরণস্বরূপ approved, lgtm, release-note) এবং চেরি পিকের শেষকার পূর্বে CI টেস্ট পাস করতে হবে। এটা সাধারণত লক্ষ্য করা হয় লক্ষ্য রিলিজের দুই দিন পূর্বে, তবে এটা আরও হতে পারে। পিআরের প্রস্তুতি যে পরিপ্রেক্ষিতে তা অনেক ভাল, কারণ আমাদের যখন চেরি পিক আপনার চেরি পিক মানচিত্রে মারার পূর্বে CI সিগনাল পেতে সময় লাগে।

চেরি পিক PR গুলো, যেগুলো মার্জ মানদন্ড মিস করবে, সেগুলো অনুসরণ এবং ট্রাক করা হবে পরবর্তী প্যাঁচ রিলিজ এর জন্য ।

সাপোর্ট পিরিয়ড

বার্ষিক সাপোর্ট KEP অনুসারে, কুবারনেটিস কমিউনিটি প্রায় চৌদ্দ (১৪) মাসের জন্য সক্রিয় প্যাচ রিলিজ সিরিজের সমর্থন করবে।

এই সময়সীমার প্রথম বারো মাসগুলি স্ট্যান্ডার্ড পিরিয়ড হিসাবে গণ্য হবে।

বারো মাসের শেষে, নিম্নলিখিত ঘটনা ঘটবে:

• রিলিজ ম্যানেজার একটি রিলিজ কাটবে
• প্যাচ রিলিজ সিরিজটি মেইন্টেনেন্স মোডে প্রবেশ করবে

দুই মাসের মেইন্টেনেন্স মোডে অবস্থানের সময়সীমার দায়িত্ব মোডে রিলিজ ম্যানেজাররা অতিরিক্ত মেইন্টেনেন্স রিলিজ কাটতে পারেন যাতে নিম্নলিখিত সমস্যাগুলি সমাধান করা যায়:

• ভালনারেবিলিটি যার একটি নির্দিষ্ট CVE আইডি রয়েছে (সিকিউরিটি রেসপন্স কমিটির পরামর্শে)
• ডিপেন্ডেন্সি সমস্যাগুলি (বেস ইমেজ আপডেট সহ)
• গুরুত্বপূর্ণ কোর কম্পোনেন্ট সমস্যাগুলি

দুই মাসের মেইন্টেনেন্স মোড সময়সীমার শেষে, প্যাচ রিলিজ সিরিজটি EOL (end of life) হিসাবে গণ্য হবে এবং সম্পর্কিত ব্রাঞ্চে চেরি পিক শীঘ্রই পরে বন্ধ করা হবে

মনে রাখবেন যে, রক্ষণাবেক্ষণ মোড এবং EOL লক্ষ্যের জন্য মাসের 28 তারিখ বেছে নেওয়া হয়েছিল সরলতার জন্য (প্রতি মাসে এটি আছে)।

আগামী মাসিক রিলিজ

বাগ ফিক্সের গুরুত্বের সাথে সময়সীমা পরিবর্তন করতে পারে, তবে আমরা সহজে পরিকল্পনা করতে নিম্নলিখিত মাসিক রিলিজ পয়েন্টগুলির লক্ষ্য করব। অপরিকল্পিত, গুরুত্বপূর্ণ রিলিজগুলি এদের মধ্যেও ঘটতে পারে।

সক্রিয় শাখাগুলির জন্য বিস্তারিত রিলিজ ইতিহাস

1.32

পরবর্তী প্যাচ রিলিজ হয় 1.32.1.

1.32 enters maintenance mode on 28 ডিসেম্বর, 2025 and End of Life is on 28 ফেব, 2026.

1.31

পরবর্তী প্যাচ রিলিজ হয় 1.31.5.

1.31 enters maintenance mode on 28 আগস্ট, 2025 and End of Life is on 28 অক্টোবর, 2025.

1.30

পরবর্তী প্যাচ রিলিজ হয় 1.30.9.

1.30 enters maintenance mode on 28 এপ্রিল, 2025 and End of Life is on 28 জুন, 2025.

1.29

পরবর্তী প্যাচ রিলিজ হয় 1.29.13.

1.29 enters maintenance mode on 28 ডিসেম্বর, 2024 and End of Life is on 28 ফেব, 2025.

অসক্রিয় শাখা ইতিহাস

এই রিলিজগুলি আর সমর্থিত নয়।

4 - ভার্সন Skew পলিসি

এই ডকুমেন্টটি কুবারনেটিসের বিভিন্ন উপাদানগুলির মধ্যে সর্বাধিক ভার্সন skew সাপোর্টেড বর্ণনা করে। নির্দিষ্ট ক্লাস্টার সরঞ্জামগুলি ভার্সন skew অতিরিক্ত সীমাবদ্ধতা স্থাপন করতে পারে৷

সাপোর্টেড ভার্সনগুলি

কুবারনেটিস ভার্সন x.y.z হিসাবে প্রকাশ করা হয়, যেখানে x হল মুখ্য ভার্সন, y হল গৌণ ভার্সন এবং z হল প্যাচ ভার্সন (patch version), যা শব্দার্থিক ভার্সন পরিভাষা অনুসরণ করে হয়। অতিরিক্ত তথ্যসমূহের জন্য, দেখুন কুবারনেটিস রিলিজ ভার্সন।

কুবারনেটিস প্রজেক্ট সাম্প্রতিক তিনটি পর্যন্ত ছোট রিলিজের জন্য রিলিজ শাখা বজায় রাখে (1.32, 1.31, 1.30)। কুবারনেটিস 1.19 এবং নতুন ভার্সন আনুমানিক 1 বছরের প্যাচ সাপোর্ট পায়(patch support) কুবারনেটিস 1.18 এবং তার বেশি বয়সীরা প্রায় 9 মাস প্যাচ সাপোর্ট (patch support) পেয়েছে।

প্রযোজ্য সংশোধন, নিরাপত্তা সংশোধন সহ, তীব্রতা এবং সম্ভাব্যতার উপর নির্ভর করে, সেই তিনটি রিলিজ শাখায় ব্যাকপোর্ট করা যেতে পারে। প্যাচ রিলিজগুলি এই শাখাগুলি থেকে একটি নিয়মিত ক্যাডেন্স এ কাটা হয়, এবং প্রয়োজনে অতিরিক্ত জরুরী রিলিজগুলি।

এ রিলিজ ম্যানেজার গ্রুপ এই সিদ্ধান্তের মালিক।

আরও তথ্যের জন্য, কুবারনেটিস প্যাচ রিলিজ পৃষ্ঠাটি দেখুন।

ভার্সন সাপোর্টেড skew

kube-apiserver

অত্যন্ত-উপলব্ধ (HA) ক্লাস্টারে,, নতুন এবং প্রাচীনতম kube-apiserver উদাহরণগুলি অবশ্যই একটি ছোট ভার্সনের মধ্যে থাকতে হবে৷

উদাহরণ:

• নতুন kube-apiserver 1.32 এ আছে
• অন্যান্য kube-apiserver ইন্সট্যান্সগুলি 1.32 এবং 1.31 এ সাপোর্টেড

kubelet

• kubelet নতুন হওয়া উচিত নয় kube-apiserver এর চেয়ে।
• kubelet তিনটি ছোট ভার্সন পর্যন্ত পুরানো হতে পারে kube-apiserver এর চেয়ে (kubelet < 1.25 শুধুমাত্র দুটি ছোট ভার্সন পর্যন্ত পুরানো হতে পারে kube-apiserver এর চেয়ে).

উদাহরণ:

• kube-apiserver 1.32 এ আছে
• kubelet 1.32, 1.31, 1.30, এবং 1.29 সাপোর্টেড

উদাহরণ:

• kube-apiserver ইন্সট্যান্সগুলিতে 1.32 এবং 1.31 আছে
• kubelet 1.31, 1.30, এবং 1.29 এ সাপোর্টেড (1.32 সাপোর্টেড নয় কারণ এটি ভার্সন 1.31 -এ kube-apiserver ইন্সট্যান্সের চেয়ে নতুন হবে)

kube-proxy

• kube-proxy নতুন হওয়া উচিত নয় kube-apiserver এর চেয়ে।
• kube-proxy তিনটি ছোট ভার্সন পর্যন্ত পুরানো হতে পারে kube-apiserver এর চেয়ে (kube-proxy < 1.25 শুধুমাত্র দুটি ছোট ভার্সন পর্যন্ত পুরানো হতে পারে kube-apiserver) এর চেয়ে।
• kube-proxy তিনটি ছোট ভার্সন পর্যন্ত পুরানো বা নতুন হতে পারে kubelet ইন্সট্যান্সের(instance) থেকে পাশাপাশি এটি চলে (kube-proxy < 1.25 শুধুমাত্র দুটি ছোট ভার্সন পর্যন্ত পুরানো বা নতুন হতে পারে kubelet ইন্সট্যান্সের থেকে পাশাপাশি এটি চলে )।

উদাহরণ:

• kube-apiserver 1.32 এ আছে
• kube-proxy তে 1.32, 1.31, 1.30, এবং 1.29 এ সাপোর্টেড

উদাহরণ:

• kube-apiserver ইন্সট্যান্সে 1.32 এবং 1.31 আছে
• kube-proxy 1.31, 1.30, এবং 1.29 এ সাপোর্টেড (1.32 সাপোর্টেড নয় কারণ এটি ভার্সন 1.31 -এ kube-apiserver ইন্সট্যান্সের চেয়ে নতুন হবে)

kube-controller-manager, kube-scheduler, and cloud-controller-manager

kube-controller-manager, kube-scheduler, এবং cloud-controller-manager নতুন হওয়া উচিত নয় kube-apiserver থেকে ইন্সট্যান্সগুলির সাথে তারা যোগাযোগ করে। তারা kube-apiserver ক্ষুদ্র ভার্সনের সাথে মিলবে বলে আশা করা হচ্ছে, কিন্তু একটি ছোট ভার্সন পর্যন্ত পুরানো হতে পারে (লাইভ আপগ্রেডের অনুমতি দেওয়ার জন্য)।

উদাহরণ:

• kube-apiserver 1.32 এ আছে
• kube-controller-manager, kube-scheduler, এবং cloud-controller-manager সাপোর্টেড আছে 1.32 এবং 1.31

উদাহরণ:

• kube-apiserver ইন্সট্যান্সে 1.32 এবং 1.31 আছে
• kube-controller-manager, kube-scheduler, এবং cloud-controller-manager একটি লোড ব্যালেন্সারের সাথে যোগাযোগ করে যে কোনো kube-apiserver ইন্সট্যান্সে রুট করতে পারে
• kube-controller-manager, kube-scheduler, এবং cloud-controller-manager সাপোর্টেড আছে 1.31 (1.32 সাপোর্টেড নয় কারণ এটি 1.31 ভার্সনে নতুন হবে kube-apiserver ইন্সট্যান্সের চেয়ে নতুন হবে)

kubectl

kubectl একটি ছোট ভার্সন (পুরানো বা নতুন) kube-apiserver এর মধ্যে সাপোর্টেড।

উদাহরণ:

• kube-apiserver আছে 1.32
• kubectl সাপোর্টেড আছে 1.33, 1.32, এবং 1.31

উদাহরণ:

• kube-apiserver ইন্সট্যান্সে আছে 1.32 এবং 1.31
• kubectl সাপোর্টেড আছে 1.32 এবং 1.31 (অন্যান্য ভার্সনগুলি kube-apiserver উপাদানগুলির একটি থেকে একের বেশি ছোটখাট ভার্সন হবে )

সাপোর্টেড উপাদান আপগ্রেড অর্ডার

উপাদানগুলির মধ্যে সাপোর্টেড ভার্সনের স্কুটির প্রভাব রয়েছে যে ক্রম অনুসারে উপাদানগুলিকে আপগ্রেড করতে হবে৷ এই বিভাগটি 1.31 ভার্সন থেকে 1.32 ভার্সনে একটি বিদ্যমান ক্লাস্টার রূপান্তর করতে উপাদানগুলিকে আপগ্রেড করতে হবে তা বর্ণনা করে৷

ঐচ্ছিকভাবে, আপগ্রেড করার প্রস্তুতির সময়, কুবারনেটিস প্রজেক্ট সুপারিশ করে যে আপনি আপগ্রেড করার সময় যতটা সম্ভব রিগ্রেশন এবং বাগ ফিক্স থেকে উপকৃত হতে নিম্নলিখিতগুলি করুন:

• নিশ্চিত করুন যে উপাদানগুলি আপনার বর্তমান ছোট ভার্সনের সবচেয়ে সাম্প্রতিক প্যাচ ভার্সনে রয়েছে৷
• ক্ষুদ্র লক্ষ্য ভার্সনের সবচেয়ে সাম্প্রতিক প্যাচ ভার্সনে উপাদান আপগ্রেড করুন।

উদাহরণস্বরূপ, আপনি যদি 1.31 ভার্সন চালাচ্ছেন, তাহলে নিশ্চিত করুন যে আপনি সাম্প্রতিক প্যাচ ভার্সনে আছেন৷ তারপর, 1.32-এর সবচেয়ে সাম্প্রতিক প্যাচ ভার্সনে আপগ্রেড করুন৷

kube-apiserver

পূর্বশর্তসমূহ:

• একটি একক-ইন্সট্যান্স ক্লাস্টারে, বিদ্যমান kube-apiserver ইন্সট্যান্স হল 1.31
• একটি HA ক্লাস্টারে, সমস্ত kube-apiserver ইন্সট্যান্সগুলি 1.31 বা 1.32 এ থাকে (এটি প্রাচীনতম এবং নতুন kube-apiserver ইন্সট্যান্সের মধ্যে সর্বাধিক 1 টি ছোট ভার্সন নিশ্চিত করে )
• এই সার্ভারের সাথে যোগাযোগকারী কুব-কন্ট্রোলার-ম্যানেজার, কুব-শিডিউলার এবং ক্লাউড-কন্ট্রোলার-ম্যানেজার ইনস্ট্যান্সগুলি 1.31 ভার্সনে রয়েছে (এটি নিশ্চিত করে যে তারা বিদ্যমান API সার্ভার ভার্সনের চেয়ে নতুন নয় ,এবং এর মধ্যে রয়েছে নতুন API সার্ভার ভার্সনের 1টি ছোট ভার্সন)
• সমস্ত নোডের kubelet ইনস্ট্যান্সগুলি 1.31 or 1.30 ভার্সনে রয়েছে (এটি নিশ্চিত করে যে তারা বিদ্যমান API সার্ভার ভার্সনের চেয়ে নতুন নয় ,এবং নতুন API সার্ভার ভার্সনের 2টি ছোট ভার্সনের মধ্যে রয়েছে)
• নিবন্ধিত ভর্তির ওয়েবহুকগুলি নতুন কুবে-এপিসার্ভার ইনস্ট্যান্স যে ডেটা পাঠাবে তা পরিচালনা করতে সক্ষম:
  • ValidatingWebhookConfiguration এবং MutatingWebhookConfiguration অবজেক্ট অন্তর্ভুক্ত করার জন্য আপডেট করা হয়েছে REST রিসোর্সের যেকোন নতুন ভার্সন 1.32 এ যোগ করা হয়েছে (বা ব্যবহার করুন matchPolicy: Equivalent option v1.15+ এ সহজলভ্য)
  • ওয়েবহুকগুলি REST সংস্থানগুলির যে কোনও নতুন ভার্সন পরিচালনা করতে সক্ষম যা তাদের কাছে পাঠানো হবে, এবং 1.32-এ বিদ্যমান ভার্সনগুলিতে যে কোনও নতুন ক্ষেত্র যুক্ত করা হবে।

kube-apiserver আপগ্রেড করুন 1.32

kube-controller-manager, kube-scheduler, and cloud-controller-manager

পূর্বশর্তসমূহ:

• kube-apiserver ইনস্ট্যান্সগুলির সাথে এই উপাদানগুলি 1.32 -এ যোগাযোগ করে (HA ক্লাস্টারে যেখানে এই কন্ট্রোল প্লেন উপাদানগুলি ক্লাস্টারের যেকোনো kube-apiserver ইনস্ট্যান্সের সাথে যোগাযোগ করতে পারে, এই উপাদানগুলি আপগ্রেড করার আগে সমস্ত kube-apiserver ইনস্ট্যান্সগুলি আপগ্রেড করা আবশ্যক)

1.32 থেকে আপগ্রেড করুন kube-controller-manager, kube-scheduler, এবং cloud-controller-manager । kube-controller-manager, kube-scheduler, cloud-controller-manager এর মধ্যে কোনো প্রয়োজনীয় আপগ্রেড অর্ডার নেই। আপনি যে কোনো ক্রমে এই উপাদান আপগ্রেড করতে পারেন, বা এমনকি একই সাথে।

kubelet

পূর্বশর্তসমূহ:

• যে kube-apiserver ইনস্ট্যান্স kubelet এর সাথে যোগাযোগ করে তা 1.32-এ।

ঐচ্ছিকভাবে kubelet ইনস্ট্যান্সগুলিকে 1.32 তে আপগ্রেড করুন (অথবা সেগুলি 1.31, 1.30, বা 1.29 এ ছেড়ে দেওয়া যেতে পারে)

kube-proxy

পূর্বশর্তসমূহ:

• যে kube-apiserver ইনস্ট্যান্স kube-proxy এর সাথে যোগাযোগ করে তা 1.32-এ।

ঐচ্ছিকভাবে kube-proxy ইনস্ট্যান্সগুলিকে 1.32 তে আপগ্রেড করুন (অথবা সেগুলি 1.31, 1.30, বা 1.29 এ ছেড়ে দেওয়া যেতে পারে)

5 - নোটস

আপনার কুবারনেটিস সংস্করণের সাথে মেলে এমন চেঞ্জলগ (Changelog) পড়ার মাধ্যমে রিলিজ নোট পাওয়া যাবে। 1.32-এর চেঞ্জলগ দেখুন গিটহাব ।

বিকল্পভাবে, রিলিজ নোটস অনলাইনে অনুসন্ধান এবং ফিল্টার করা যেতে পারে: relnotes.k8s.io। 1.32-এর জন্য ফিল্টার করা রিলিজ নোটগুলো দেখুন relnotes.k8s.io।

6 - রিলিজ ম্যানেজারস

"রিলিজ ম্যানেজাররা" হল একটি সার্বিক শব্দ যা কুবারনেটিসের সেই অবদানকারীদের নির্দেশ করে, যারা রিলিজ ব্রাঞ্চগুলি বজায় রাখা এবং SIG Release দ্বারা সরবরাহিত টুলগুলি ব্যবহার করে রিলিজ তৈরি করার দায়িত্বে থাকে।

প্রত্যেক ভূমিকার দায়িত্ব নীচে বর্ণিত হয়েছে।

• যোগাযোগ

  • নিরাপত্তা ইম্বার্গো নীতি

• হ্যান্ডবুক

• রিলিজ ম্যানেজারস

  • রিলিজ ম্যানেজার হওয়া

• রিলিজ ম্যানেজার অ্যাসোসিয়েটস

  • রিলিজ ম্যানেজার অ্যাসোসিয়েট হওয়া

• SIG রিলিজ লিডস

  • চেয়ারস
  • টেকনিক্যাল লিডস

  যোগাযোগ

নিরাপত্তা ইম্বার্গো নীতি

কিছু রিলিজ সম্পর্কিত তথ্য ইম্বার্গোর অধীনে রয়েছে এবং আমরা তারা সেট করার জন্য নীতি নির্ধারণ করেছি। অধিক তথ্যের জন্য দয়া করে নিরাপত্তা ইম্বার্গো নীতি দেখুন।

হ্যান্ডবুক

লক্ষ্যস্থান: প্যাচ রিলিজ টীম এবং শাখা ম্যানেজার হ্যান্ডবুকগুলি পরের তারিখে ডিডুপ্লিকেট করা হবে।

• প্যাচ রিলিজ টীম
• শাখা ম্যানেজার

রিলিজ ম্যানেজার

নোট: ডকুমেন্টেশনে প্যাচ রিলিজ টিম এবং ব্রাঞ্চ ম্যানেজমেন্ট ভূমিকা সম্পর্কে উল্লেখ থাকতে পারে। এই দুই ভূমিকা রিলিজ ম্যানেজার ভূমিকায় একীভূত করা হয়েছে।

মিনিমাম প্রয়োজনীয়তা রিলিজ ম্যানেজার এবং রিলিজ ম্যানেজার অ্যাসোসিয়েটগুলির জন্য নিম্নলিখিত:

• বেসিক ইউনিক্স কমান্ডের পরিচিতি এবং শেল স্ক্রিপ্ট ডিবাগ করতে পারা।
• git এবং সম্পর্কিত git কমান্ড লাইন ইনভোকেশন এর মাধ্যমে ব্রাঞ্চ সোর্স কোড ওয়ার্কফ্লো পরিচিতি।
• গুগল ক্লাউডের সাধারণ জ্ঞান (ক্লাউড বিল্ড এবং ক্লাউড স্টোরেজ)।
• সাহায্য চাওয়া এবং স্পষ্টভাবে যোগাযোগের জন্য উন্মুক্ত।
• কুবার্নিটিস কমিউনিটি সদস্যতা

রিলিজ ম্যানেজারদের দায়িত্ব অনুসারে:

• কুবার্নিটিস রিলিজ করা এবং সমন্বয় করা:
  • প্যাচ রিলিজ (x.y.z, যেখানে z > 0)
  • মাইনর রিলিজ (x.y.z, যেখানে z = 0)
  • প্রি-রিলিজ (আলফা, বেটা এবং রিলিজ ক্যান্ডিডেট)
  • প্রতিটি রিলিজ চক্রে রিলিজ টিম সঙ্গে কাজ করা
  • প্যাচ রিলিজের জন্য সময়সূচি এবং ক্যাডেন্স নির্ধারণ করা
• রিলিজ ব্রাঞ্চগুলি মেন্টেনেন্স করা:
  • চেরি পিকগুলি পর্যালোচনা করা
  • রিলিজ ব্রাঞ্চটি স্বাস্থ্যকর রাখা এবং কোনও অপ্রত্যাশিত প্যাচ মার্জ না হয়ে থাকা নিশ্চিত করা ।
• রিলিজ ম্যানেজার অ্যাসোসিয়েটগুলির গ্রুপ মেন্টরিং করা
• k/release এ বৈশিষ্ট্যগুলি উন্নত করা এবং কোড রক্ষণ করা
• Buddy প্রোগ্রামে সক্রিয়ভাবে অংশগ্রহণের মাধ্যমে রিলিজ ম্যানেজার সহযোগী এবং অবদানকারীদের সহায়তা করা
  • মাসিকভাবে অ্যাসোসিয়েটগুলির সাথে চেক ইন করুন এবং কাজ দেয়ার জন্য তাদের সামর্থ্য বৃদ্ধি করুন, তাদেরকে রিলিজ করতে সাহায্য করুন এবং মেন্টরিং করুন
  • অ্যাসোসিয়েটগুলির নতুন অবদানকারীদের নিয়োগে সহায়তা করা যেমন, প্রশ্নের উত্তর দেওয়া এবং তাদের জন্য উপযুক্ত কাজের পরামর্শ দেওয়া

এই দলটি মাঝে মাঝে সিকিউরিটি রেসপন্স কমিটির সাথে ঘনিষ্ঠভাবে কাজ করে এবং তাই সিকিউরিটি রিলিজ প্রসেসে উল্লিখিত নির্দেশিকা মেনে চলা উচিত।

GitHub অ্যাক্সেস নিয়ন্ত্রণ: @kubernetes/release-managers

GitHub উল্লেখ: @kubernetes/release-engineering

• Adolfo García Veytia (@puerco)
• Cici Huang (@cici37)
• Carlos Panato (@cpanato)
• Jeremy Rickard (@jeremyrickard)
• Marko Mudrinić (@xmudrii)
• Nabarun Pal (@palnabarun)
• Sascha Grunert (@saschagrunert)
• Stephen Augustus (@justaugustus)
• Verónica López (@verolop)

রিলিজ ম্যানেজার হওয়ার পথ

রিলিজ ম্যানেজার হতে চাইলে, প্রথমে কাউকে রিলিজ ম্যানেজার অ্যাসোসিয়েট হিসেবে কাজ করতে হবে। অ্যাসোসিয়েটরা কয়েকটি চক্র জুড়ে রিলিজের উপর সক্রিয়ভাবে কাজ করে রিলিজ ম্যানেজারে পদোন্নতি পায়:

• নেতৃত্ব দেওয়ার ইচ্ছা প্রদর্শন করা
• রিলিজ ম্যানেজারদের সাথে ট্যাগ-টিম করে প্যাচগুলিতে কাজ করা, শেষ পর্যন্ত স্বাধীনভাবে একটি রিলিজ কাটা যায় ।
  • রিলিজের একটি সীমাবদ্ধ কার্যকারিতা থাকার কারণে, আমরা ইমেজ প্রচার এবং অন্যান্য কোর রিলিজ ইঞ্জিনিয়ারিং কাজের উল্লেখযোগ্য অবদানকেও মূল্যায়ন করি ।
• অ্যাসোসিয়েটদের কাজ কিভাবে হচ্ছে তা জিজ্ঞাসাবাদ করা, উন্নতির প্রস্তাবনা দেওয়া, ফিডব্যাক সংগ্রহ করা এবং পরিবর্তন চালনা করা
• নির্ভরযোগ্য এবং দ্রুত সাড়া দেওয়া ।
• এমন উন্নত কাজে নিজেকে নিযুক্ত করা যা সম্পন্ন করতে রিলিজ ম্যানেজার-স্তরের অ্যাক্সেস এবং সুবিধার প্রয়োজন ।

রিলিজ ম্যানেজার অ্যাসোসিয়েটস

রিলিজ ম্যানেজার অ্যাসোসিয়েটরা হলেন রিলিজ ম্যানেজারদের শিক্ষানবিশ, যাদের আগে রিলিজ ম্যানেজার শ্যাডো হিসেবে পরিচিত করা হতো। তাদের দায়িত্ব হল:

• প্যাচ রিলিজের কাজ, চেরি পিক রিভিউ
• k/release আপডেট করা: নির্ভরশীলতা আপডেট করা এবং সোর্স কোডবেজে অভ্যস্ত হওয়া
• ডকুমেন্টেশনে অবদান রাখা: হ্যান্ডবুকগুলি মেনটেইন করা, নিশ্চিত করা যে রিলিজ প্রক্রিয়াগুলি ডকুমেন্টেড হয়েছে
• একজন রিলিজ ম্যানেজারের সাহায্যে: রিলিজ টিমের সাথে রিলিজ চক্রের সময় কাজ করা এবং কুবেরনেটস রিলিজ কাটা
• অগ্রাধিকার এবং যোগাযোগে সাহায্যের সুযোগ খুঁজে বের করা
  • প্যাচ রিলিজ সম্পর্কে প্রাক-ঘোষণা এবং আপডেট পাঠানো
  • ক্যালেন্ডার আপডেট করা, রিলিজের তারিখ এবং মাইলস্টোনগুলির সাথে সাহায্য করা রিলিজ চক্রের টাইমলাইন থেকে
• Buddy প্রোগ্রামের মাধ্যমে, নতুন অবদানকারীদের অনবোর্ডিং করা এবং তাদের সাথে কাজের জুটি বাঁধা

GitHub মেনশনস: @kubernetes/release-engineering

• Arnaud Meukam (@ameukam)
• Jim Angel (@jimangel)
• Joseph Sandoval (@jrsapi)
• Xander Grzywinski (@salaxander)

রিলিজ ম্যানেজার অ্যাসোসিয়েট হওয়ার পথ

অবদানকারীরা নিম্নলিখিত দেখানোর মাধ্যমে অ্যাসোসিয়েট হতে পারেন:

• নিয়মিত অংশগ্রহণ, যার মধ্যে ৬-১২ মাসের সক্রিয় রিলিজ ইঞ্জিনিয়ারিং-সম্পর্কিত কাজ অন্তর্ভুক্ত

• একটি রিলিজ চক্রে রিলিজ টিমে একজন টেকনিকাল লিড হিসেবে ভূমিকা পালনের অভিজ্ঞতা

  • SIG রিলিজ সামগ্রিকভাবে কীভাবে কাজ করে তা বোঝার জন্য এই অভিজ্ঞতাটি একটি শক্ত ভিত্তিরেখা প্রদান করে—যার মধ্যে প্রযুক্তিগত দক্ষতা, যোগাযোগ/রেস্পন্সিভনেস এবং নির্ভরযোগ্যতা সম্পর্কিত আমাদের প্রত্যাশাগুলি অন্তর্ভুক্ত

• k/release আইটেমগুলিতে কাজ করা যা Testgrid এর সাথে আমাদের ইন্টার‌্যাকশন এর উন্নত করে, লাইব্রেরি পরিষ্কার করা ইত্যাদি কাজে অবদান রাখা

  • এই প্রচেষ্টাগুলি রিলিজ ম্যানেজারদের এবং অ্যাসোসিয়েটদের সাথে ইন্টার‌্যাক্ট করা এবং জুটি বাঁধা প্রয়োজন

  SIG রিলিজ লিডস

SIG রিলিজ চেয়ারস এবং টেকনিকাল লিডস দায়ী আছেন:

• SIG রিলিজের গভর্নেন্সের জন্য
• রিলিজ ম্যানেজার এবং অ্যাসোসিয়েটদের জন্য জ্ঞান বিনিময় সেশন নেতৃত্ব দান
• নেতৃত্ব এবং অগ্রাধিকার নির্ধারণে কোচিং প্রদান

তাদের এখানে স্পষ্টভাবে উল্লেখ করা হয়েছে কারণ তারা প্রতিটি ভূমিকার জন্য বিভিন্ন যোগাযোগ চ্যানেল এবং অনুমতি গ্রুপ (GitHub টিমস, GCP অ্যাক্সেস) এর মালিক। এই হিসাবে, তারা অত্যন্ত অধিকারপ্রাপ্ত কমিউনিটি সদস্য এবং কিছু ব্যক্তিগত যোগাযোগের জন্য সচেতন, যা কখনো কখনো কুবারনেটিস নিরাপত্তা প্রকাশনার সাথে সম্পর্কিত হতে পারে।

GitHub টিম: @kubernetes/sig-release-leads

চেয়ারস

• Jeremy Rickard (@jeremyrickard)
• Sascha Grunert (@saschagrunert)
• Stephen Augustus (@justaugustus)

টেকনিকাল লিডস

• Adolfo García Veytia (@puerco)
• Carlos Panato (@cpanato)
• Verónica López (@verolop)

পূর্ববর্তী শাখা ম্যানেজারদের তালিকা releases directory-এ kubernetes/sig-release রিপোজিটরিতে release-x.y/release_team.md ফাইলে পাওয়া যাবে।

উদাহরণ: 1.15 Release Team