কুবারনেটিস প্রজেক্ট সাম্প্রতিক তিনটি পর্যন্ত ছোট রিলিজের জন্য রিলিজ শাখা বজায় রাখে। (1.35, 1.34, 1.33). কুবারনেটিস 1.19 এবং নতুন ভার্সন আনুমানিক 1 বছরের প্যাচ সাপোর্ট পায়(patch support) কুবারনেটিস 1.18 এবং তার বেশি বয়সীরা প্রায় 9 মাস প্যাচ সাপোর্ট (patch support) পেয়েছে।
কুবারনেটিস সংস্করণ x.y.z হিসাবে প্রকাশ করা হয়, যেখানে x হল মুখ্য সংস্করণ, y হল গৌণ সংস্করণ এবং z হল প্যাচ ভার্সন (patch version), যা শব্দার্থিক সংস্করণ পরিভাষা অনুসরণ করে হয়।
অতিরিক্ত তথ্যসমূহ version skew policy নথিতে সংরক্ষিত রয়েছে।
চেক করুন সময়সূচী আসন্ন 1.36 কুবারনেটিস রিলিজ!
কুবারনেটিস প্রতিটি উপাদানের জন্য বাইনারি পাঠায় সেইসাথে একটি ক্লাস্টারের সাথে বুটস্ট্র্যাপ বা ইন্টারঅ্যাক্ট (interact) করার জন্য ক্লায়েন্ট অ্যাপ্লিকেশনগুলোর একটি আদর্শ সেটও পাঠায়। এপিআই সার্ভারের মতো উপাদানগুলো একটি ক্লাস্টারের ভিতরে কন্টেইনার ইমেজগুলোর মধ্যে চলতে সক্ষম। সেই উপাদানগুলো অফিসিয়াল রিলিজ প্রক্রিয়ার অংশ হিসাবে কন্টেইনার ইমেজেও পাঠানো হয়। সমস্ত বাইনারি এবং সেইসাথে কন্টেইনার ইমেজ একাধিক অপারেটিং সিস্টেমের পাশাপাশি একাধিক হার্ডওয়্যার আর্কিটেকচারের জন্য উপলব্ধ (available)।
কুবারনেটিস কমান্ড-লাইন টুল, kubectl, আপনাকে কুবারনেটিস ক্লাস্টারগুলোর বিপরীতে কমান্ড চালানোর অনুমতি দেয়।
আপনি অ্যাপ্লিকেশন স্থাপন(deploy) করতে, ক্লাস্টার রিসোর্স পরিদর্শন ও পরিচালনা করতে এবং লগ দেখতে kubectl
ব্যবহার করতে পারেন। kubectl অপারেশনগুলোর একটি সম্পূর্ণ তালিকা সহ আরও তথ্যের জন্য,
kubectl রেফারেন্স ডকুমেন্টেশন দেখুন।
kubectl বিভিন্ন লিনাক্স প্ল্যাটফর্ম, ম্যাকওস এবং উইন্ডোজে ইনস্টলযোগ্য। নীচে আপনার পছন্দের অপারেটিং সিস্টেম খুঁজুন।
সমস্ত কুবারনেটিস কন্টেইনার ছবি registry.k8s.io
কন্টেইনার ইমেজ রেজিস্ট্রিতে স্থাপন করা হয় ।
| কন্টেইনার ইমেজ | সাপোর্টেড আর্কিটেকচার |
|---|---|
| registry.k8s.io/kube-apiserver:v1.35.0 | amd64, arm, arm64, ppc64le, s390x |
| registry.k8s.io/kube-controller-manager:v1.35.0 | amd64, arm, arm64, ppc64le, s390x |
| registry.k8s.io/kube-proxy:v1.35.0 | amd64, arm, arm64, ppc64le, s390x |
| registry.k8s.io/kube-scheduler:v1.35.0 | amd64, arm, arm64, ppc64le, s390x |
| registry.k8s.io/conformance:v1.35.0 | amd64, arm, arm64, ppc64le, s390x |
সমস্ত কন্টেইনার ইমেজ একাধিক আর্কিটেকচারের জন্য উপলব্ধ, যেখানে কন্টেইনার
রানটাইম অন্তর্নিহিত প্ল্যাটফর্মের উপর ভিত্তি করে সঠিকটি বেছে নেওয়া উচিত।
কন্টেইনার ইমেজ নামের প্রত্যয়যোগ একটি ডেডিকেটেড আর্কিটেকচারও নেওয়া সম্ভব,
উদাহরণস্বরূপ
registry.k8s.io/kube-apiserver-arm64:v1.35.0।
কুবারনেটিস v1.26 [beta]
কুবারনেটিস 1.35 এর জন্য, কন্টেইনার ইমেজগুলো 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/'
কুবারনেটিস মূল উপাদানগুলোর স্বাক্ষরিত কন্টেইনার ইমেজগুলো ম্যানুয়ালি যাচাই করতে, স্বাক্ষরিত কন্টেইনার ইমেজগুলো যাচাই করুন।
আপনি যদি একটি নির্দিষ্ট আর্কিটেকচারের জন্য একটি কন্টেইনার ইমেজ নেন, তাহলে একক-আর্কিটেকচার ইমেজটি মাল্টি-আর্কিটেকচার ম্যানিফেস্ট তালিকার মতোই সাইন ইন করা হয়।
আপনি চেঞ্জলগ ফাইলগুলিতে কুবারনেটিস উপাদান (এবং তাদের চেকসাম) ডাউনলোড করার লিঙ্কগুলি খুঁজে পেতে পারেন। বিকল্পভাবে, ভার্সন এবং আর্কিটেকচার দ্বারা ফিল্টার করতে downloadkubernetes.com ব্যবহার করুন।
এই ডকুমেন্টটি ফোকাস করা কুবারনেটিস ডেভেলপার এবং কন্ট্রিবিউটরদের জন্য যাদের একটি এনহ্যান্সমেন্ট, ইস্যু, অথবা পুল রিকুয়েস্ট তৈরি করতে হয় যা লক্ষ্য করে একটি নির্দিষ্ট মাইলফলক।
একটি Kubernetes রিলিজে বর্ধিতকরণ, সমস্যা, এবং পুল অনুরোধের শেফারডিং(shepherding) প্রক্রিয়া একাধিক স্টেকহোল্ডারকে বিস্তৃত করে:
ওয়ার্কফ্লো এবং ইন্টারেকশন সম্পর্কিত তথ্য নীচে বর্ণিত হয়েছে।
একটি এনহ্যান্সমেন্ট, ইস্যু, অথবা পুল রিকুয়েস্ট (PR) এর ওনার হিসেবে, এটি আপনার দায়িত্ব রিলিজ মাইলস্টোন রিকোয়ারমেন্ট পূরণ হয়েছে নিশ্চিত করা। অটোমেশন এবং রিলিজ টিম আপনার সাথে যোগাযোগ করবে যদি আপডেট প্রয়োজন হয়, কিন্তু নিষ্ক্রিয়তার ফলে আপনার কাজ মাইলস্টোন থেকে সরে যেতে পারে। অতিরিক্ত রিকোয়ারমেন্ট প্রয়োজন যখন লক্ষ্য মাইলস্টোন একটি পূর্ববর্তী রিলিজ (আরও তথ্যের জন্য চেরি পিক প্রোসেস দেখ)
আপনি যদি আপনার PR মার্জ করাতে চান তার জন্য নিম্নলিখিত প্রয়োজনীয় লেবেল এবং মাইলস্টোনগুলো প্রয়োজন, এখানে Prow /commands দ্বারা প্রতিনিধিত্ব করা হয়েছে যেগুলি যোগ করা লাগবে:
'নরমাল ডেভ' পর্যায়ের ফিরে যাওয়ার রিকোয়ারমেন্ট:
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/enhancementskubernetes/kuberneteskubernetes/releasekubernetes/sig-releasekubernetes/test-infraতৈরি করার সময়, master ব্রাঞ্চের বিপরীতে PR গুলোর মানুষের দেওয়া নির্দেশনা প্রয়োজন কোন
মাইলস্টোন টার্গেট করতে হবে তার জন্য। একবার মার্জ হলে,
master ব্রাঞ্চের বিপরীতে তৈরি করা PR গুলোয় মাইলস্টোন় স্বয়ংক্রিয়ভাবে প্রয়োগ করা হয় তাই সেই সময় থেকে
ওই PR এর মাইলস্টোনে মানুষের ব্যবস্থাপনা কম প্রয়োজনীয়। রিলিজ ব্রাঞ্চ এর বিপরীতে তৈরি PR এ,
মাইলস্টোন সংক্রিয়ভাবে প্রয়োগ হয় তাই মানুষবিহীন
ব্যবস্থাপনা মাইলস্টোনের জন্য সবসময় প্রয়োজন।
অন্য কোনো প্রচেষ্টা যা রিলিজ টিমের দ্বারা ট্র্যাক করা উচিত যা কোনো অটোমেশন আম্ব্রেলার অধীনে নেই তাতে একটি মাইলফলক প্রয়োগ করা উচিত।
ইমপ্লিমেন্টেশন এবং বাগ ফিক্সিং পুরো সাইকেল জুড়ে চলেছে, কিন্তু শেষ হয় কোড-ফ্রিজ সময়কালে।
কোড ফ্রিজ শুরু হয় ~১২ সপ্তাহে এবং পরবর্তী ~২ সপ্তাহ পর্যন্ত চলে। এই সময়ে রিলিজ কোডবেসে শুধুমাত্র গুরুত্বপূর্ণ বাগ ফিক্স গ্রহণ করা হয়।
Code Freeze এর পরে এবং রিলিজের পূর্বে প্রায় দুই সপ্তাহের সময় রয়েছে, যা রিলিজ পূর্বে সমস্ত অবশিষ্ট গুরুত্বপূর্ণ সমস্যাগুলি সমাধান করা আবশ্যক। এটি ডকুমেন্টেশন চূড়ান্ত করার জন্য সময় দেয়।
যখন কোড বেস স্টেবল হয়, তখন মাস্টার ব্রাঞ্চটি সাধারণ উন্নতির জন্য পুনরায় খোলা হয় এবং পরবর্তী রিলিজের মাইলস্টোনে কাজ সেখানে শুরু করা হয়। বর্তমান রিলিজের জন্য অবশিষ্ট যেকোনো সংশোধন মাস্টার থেকে রিলিজ ব্রাঞ্চে চেরি-পিক করা হয়। রিলিজ ব্রাঞ্চ থেকে রিলিজ তৈরি করা হয়।
প্রত্যেকটি রিলিজ একটি বৃহৎ কুবারনেটিস লাইফসাইকের অংশ:
মাইলস্টোন আইটেম যোগ করার প্রক্রিযার অধিক দূরে যাওয়ার আগে, দয়া করে লক্ষ্য করুন:
রিলিজ টিম এর সদস্যরা মাইলস্টোন থেকে ইস্যু সরাতে পারে যদি তারা অথবা যদি দায়িত্বশীল SIG মনে করে যে সমস্যাটি বাস্তবে রিলিজ ব্লক করছে না এবং সম্ভবত সময়ের মধ্যে সমাধান হবে না।
রিলিজ দলের সদস্যরা নিম্নলিখিত কারণে অথবা এর সমান কারণে মাইলস্টোন থেকে PR-গুলি সরাতে পারেন:
রিলিজ টিমের সদস্যরা লেবেলিং এবং SIG দের সাথে যোগাযোগে সাহায্য করবে,PR কে শ্রেণীবদ্ধ করা জমাদানকারীর দায়িত্ব এবং প্রাসঙ্গিক SIG হতে সাহায্য নিশ্চিত করা যেনো PR দ্বারা কোনো ব্রেক হলে ধ্রুত সমাধানের গ্যারেন্টি দেওয়া হবে।
যেখানে অতিরিক্ত পদক্ষেপ প্রয়োজন, রিলিজ দল নিম্নলিখিত চ্যানেলের মাধ্যমে মানুষ থেকে মানুষে এস্ক্যালেশনের চেষ্টা করবে:
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 গুলোকে Prow "/milestone" কমান্ডের মাধ্যমে একটি মাইলফলককে লক্ষ্য করে চিহ্নিত করা হয়েছে।
উপরে বর্ণিত কোড ফ্রিজের সময় এটি একটি ব্লকিং প্রয়োজনীয়তা।
এখানে লেবেল এবং তাদের ব্যবহার এবং উদ্দেশ্য তালিকা আছে।
SIG মালিকের লেবেল SIG কে সংজ্ঞায়িত করে যার দিকে আমরা অগ্রসর হই যদি একটি মাইলস্টোন সমস্যা স্থবির হয় বা অতিরিক্ত মনোযোগের প্রয়োজন হয়। যদি বৃদ্ধির পরে কোন আপডেট না থাকে, তাহলে সমস্যাটি মাইলফলক থেকে স্বয়ংক্রিয়ভাবে সরানো হতে পারে।
এগুলি Prow "/sig" কমান্ডের সাথে যোগ করা হয়। যেমন SIG স্টোরেজ দায়ী লেবেল
যোগ করতে, /sig storage দিয়ে মন্তব্য করুন।
অগ্রাধিকার লেবেলগুলি ইস্যুগুলির রিলিস মাইলস্টোন থেকে বের হতে প্রারম্ভিক এস্ক্যালেশন পথ নির্ধারণে ব্যবহৃত হয়। তারা এটা নির্ধারণ করতে ব্যবহৃত হয় যে ইস্যুর সমাধানের উপরে রিলিস ব্লক করা উচিত কি না।
priority/critical-urgent: কখনই স্বয়ংক্রিয়ভাবে রিলিজ মাইলস্টোন থেকে
সরে যাবেন না; সব উপলভ্য চ্যানেলের মাধ্যমে ক্রমাগত অবদানকারী এবং SIG-এর কাছে
এগিয়ে যান।
priority/important-soon: ইস্যু মালিক এবং SIG মালিকের কাছে এগিয়ে যান; বেশ
কয়েকটি অসফল বৃদ্ধি প্রচেষ্টার পরে মাইলফলক থেকে সরে যান।
priority/important-longterm: ইস্যু মালিকদের কাছে এগিয়ে যান; 1 বার প্রচেষ্টার পরে মাইলফলক
থেকে সরে যান।
priority/important-soon এর চেয়ে কম জরুরি/সমালোচনাpriority/important-soon এর চেয়ে বেশি আক্রমনাত্মকভাবে মাইলফলক থেকে সরে গেছেইস্যুর ধরন ব্যবহার করা হয় সময়ের সাথে রিলিজের বিভিন্ন পরিবর্তন সনাক্ত করার জন্য। যা রিলিজ টিমকে ভালো ধারণা দেয় একটি দ্রুত রিলিজ কেডেন্সে কোন ইস্যু গুলো হারিয়ে যাচ্ছে তা সম্পর্কে।
রিলিজ টার্গেট করা সমস্যাগুলির জন্য, পুল অনুরোধ সহ, নিম্নলিখিত একটি সমস্যা ধরনের লেবেল সেট করা আবশ্যক:
kind/api-change: একটি API যোগ করে, অপসারণ করে বা পরিবর্তন করে।kind/bug: একটি নতুন আবিষ্কৃত বাগ সংশোধন করে।kind/cleanup: টেস্ট যোগ করা, রিফ্যাক্টরিং, পুরানো বাগ ঠিক করা।kind/design: ডিজাইনের সাথে সম্পর্কিত।kind/documentation: ডকুমেন্টেশন যোগ করে।kind/failing-test: CI টেস্ট কেস ধারাবাহিকভাবে ব্যর্থ হয়।kind/feature: নতুন ফিচার।kind/flake: CI টেস্ট কেস মাঝে মাঝে ব্যর্থতা দেখাচ্ছে।কুবারনেটিস প্যাচ রিলিজের সময়সূচি এবং দলের যোগাযোগ তথ্য।
কুবারনেটিস রিলিজ সাইকেলের সাধারণ তথ্যের জন্য, রিলিজ প্রক্রিয়া বর্ণনা দেখুন।
আমাদের সাধারণ প্যাচ রিলিজ ক্যাডেন্সের মাসিক। এটা সাধারণত একটু দ্রুত (1 থেকে 2 সপ্তাহ) হলেও, যখন একটি 1.X মাইনর রিলিজের পরে প্যাচ রিলিজের প্রথমটি হয়। গুরুত্বপূর্ণ বাগ সংশোধন আরও সাধারণ ক্যাডেন্সের বাইরে একটি আগামী রিলিজ সৃষ্টি করতে পারে। আমরা এছাড়াও লক্ষ্য করি যে প্রধান ছুটির সময়ে রিলিজ করা হবে না।
প্যাচ রিলিজ দলের সম্পূর্ণ যোগাযোগের বিস্তারিত তথ্যের জন্য রিলিজ ম্যানেজার পৃষ্ঠা দেখুন।
দয়া করে আমাদেরকে একটি কার্য দিন দিন - আমরা ভিন্ন টাইমজোন অনুযায়ী থাকতে পারি!
রিলিজের মধ্যে দলটি প্রতি সপ্তাহের ভিতরে আসা চেরি পিক অনুরোধগুলি দেখছে। দলটি চেরি পিক অনুরোধকারীদের সাথে GitHub PR, SIG চ্যানেল (স্ল্যাকে) এবং স্ল্যাকের email মাধ্যমে যোগাযোগ করবে, এবং যদি পিআরে কোনো প্রশ্ন থাকে।
চেরি পিক প্রসেস অনুসরণ করুন।
চেরি পিক গুলির জন্য গিটহাবে পার্শ্ববর্তী লেবেলসহ (উদাহরণস্বরূপ
approved, lgtm, release-note) এবং চেরি পিকের শেষকার পূর্বে CI টেস্ট পাস করতে হবে।
এটা সাধারণত লক্ষ্য করা হয় লক্ষ্য রিলিজের দুই দিন পূর্বে, তবে এটা আরও হতে পারে।
পিআরের প্রস্তুতি যে পরিপ্রেক্ষিতে তা অনেক ভাল, কারণ আমাদের যখন
চেরি পিক আপনার চেরি পিক মানচিত্রে মারার পূর্বে CI সিগনাল পেতে
সময় লাগে।
চেরি পিক PR গুলো, যেগুলো মার্জ মানদন্ড মিস করবে, সেগুলো অনুসরণ এবং ট্রাক করা হবে পরবর্তী প্যাঁচ রিলিজ এর জন্য ।
বার্ষিক সাপোর্ট KEP অনুসারে, কুবারনেটিস কমিউনিটি প্রায় চৌদ্দ (১৪) মাসের জন্য সক্রিয় প্যাচ রিলিজ সিরিজের সমর্থন করবে।
এই সময়সীমার প্রথম বারো মাসগুলি স্ট্যান্ডার্ড পিরিয়ড হিসাবে গণ্য হবে।
বারো মাসের শেষে, নিম্নলিখিত ঘটনা ঘটবে:
দুই মাসের মেইন্টেনেন্স মোডে অবস্থানের সময়সীমার দায়িত্ব মোডে রিলিজ ম্যানেজাররা অতিরিক্ত মেইন্টেনেন্স রিলিজ কাটতে পারেন যাতে নিম্নলিখিত সমস্যাগুলি সমাধান করা যায়:
দুই মাসের মেইন্টেনেন্স মোড সময়সীমার শেষে, প্যাচ রিলিজ সিরিজটি EOL (end of life) হিসাবে গণ্য হবে এবং সম্পর্কিত ব্রাঞ্চে চেরি পিক শীঘ্রই পরে বন্ধ করা হবে
মনে রাখবেন যে, রক্ষণাবেক্ষণ মোড এবং EOL লক্ষ্যের জন্য মাসের 28 তারিখ বেছে নেওয়া হয়েছিল সরলতার জন্য (প্রতি মাসে এটি আছে)।
বাগ ফিক্সের গুরুত্বের সাথে সময়সীমা পরিবর্তন করতে পারে, তবে আমরা সহজে পরিকল্পনা করতে নিম্নলিখিত মাসিক রিলিজ পয়েন্টগুলির লক্ষ্য করব। অপরিকল্পিত, গুরুত্বপূর্ণ রিলিজগুলি এদের মধ্যেও ঘটতে পারে।
| মাসিক প্যাচ রিলিজ | Cherry Pick সময়সীমা | টার্গেট তারিখ |
|---|---|---|
| এপ্রিল 2026 | ||
| মে 2026 | ||
| জুন 2026 |
পরবর্তী প্যাচ রিলিজ হয় 1.35.4.
1.35 enters maintenance mode on and End of Life is on .
| প্যাচ রিলিজ | Cherry Pick সময়সীমা | টার্গেট তারিখ | বিঃদ্রঃ |
|---|---|---|---|
| 1.35.3 | |||
| 1.35.2 | Out of band patch release to pick up a new version of Go to address several Go CVEs. No other changes. | ||
| 1.35.1 | January 2026 patches consolidated with February |
পরবর্তী প্যাচ রিলিজ হয় 1.34.7.
1.34 enters maintenance mode on and End of Life is on .
| প্যাচ রিলিজ | Cherry Pick সময়সীমা | টার্গেট তারিখ | বিঃদ্রঃ |
|---|---|---|---|
| 1.34.6 | |||
| 1.34.5 | Out of band patch release to pick up a new version of Go to address several Go CVEs. No other changes. | ||
| 1.34.4 | January 2026 patches consolidated with February | ||
| 1.34.3 | |||
| 1.34.2 | October 2025 patches consolidated with November | ||
| 1.34.1 | |||
| 1.34.0 | - |
পরবর্তী প্যাচ রিলিজ হয় 1.33.11.
1.33 enters maintenance mode on and End of Life is on .
| প্যাচ রিলিজ | Cherry Pick সময়সীমা | টার্গেট তারিখ | বিঃদ্রঃ |
|---|---|---|---|
| 1.33.10 | |||
| 1.33.9 | Out of band patch release to pick up a new version of Go to address several Go CVEs. No other changes. | ||
| 1.33.8 | January 2026 patches consolidated with February | ||
| 1.33.7 | |||
| 1.33.6 | October 2025 patches consolidated with November | ||
| 1.33.5 | |||
| 1.33.4 | |||
| 1.33.3 | |||
| 1.33.2 | |||
| 1.33.1 |
এই রিলিজগুলি আর সমর্থিত নয়।
| ক্ষুদ্র ভার্সন | চূড়ান্ত প্যাচ রিলিজ | End Of Life তারিখ | বিঃদ্রঃ |
|---|---|---|---|
| 1.32 | 1.32.13 | ||
| 1.31 | 1.31.14 | ||
| 1.30 | 1.30.14 | ||
| 1.29 | 1.29.14 | ||
| 1.28 | 1.28.15 | ||
| 1.27 | 1.27.16 | ||
| 1.26 | 1.26.15 | 1.26.15 was released in March 2024 (after the EOL date) to pick up a new version of Go to address several Go CVEs | |
| 1.25 | 1.25.16 | 1.25.16 was released in November 2023 (after the EOL date) to fix CVE-2023-5528 | |
| 1.24 | 1.24.17 | 1.24.17 was released in August 2023 (after the EOL date) to fix CVE-2023-3676 and CVE-2023-3955 | |
| 1.23 | 1.23.17 | ||
| 1.22 | 1.22.17 | 1.22.17 was released in December 2022 (after the EOL date) to backport registry changes and fix two critical issues. | |
| 1.21 | 1.21.14 | ||
| 1.20 | 1.20.15 | ||
| 1.19 | 1.19.16 | ||
| 1.18 | 1.18.20 | Created to solve regression introduced in 1.18.19 | |
| 1.17 | 1.17.17 | ||
| 1.16 | 1.16.15 | ||
| 1.15 | 1.15.12 | ||
| 1.14 | 1.14.10 | ||
| 1.13 | 1.13.12 | ||
| 1.12 | 1.12.10 | ||
| 1.11 | 1.11.10 | ||
| 1.10 | 1.10.13 | ||
| 1.9 | 1.9.11 | ||
| 1.8 | 1.8.15 | ||
| 1.7 | 1.7.16 | ||
| 1.6 | 1.6.13 | ||
| 1.5 | 1.5.8 | ||
| 1.4 | 1.4.12 | ||
| 1.3 | 1.3.10 | ||
| 1.2 | 1.2.7 |
এই ডকুমেন্টটি কুবারনেটিসের বিভিন্ন উপাদানগুলির মধ্যে সর্বাধিক ভার্সন skew সাপোর্টেড বর্ণনা করে। নির্দিষ্ট ক্লাস্টার সরঞ্জামগুলি ভার্সন skew অতিরিক্ত সীমাবদ্ধতা স্থাপন করতে পারে৷
কুবারনেটিস ভার্সন x.y.z হিসাবে প্রকাশ করা হয়, যেখানে x হল মুখ্য ভার্সন, y হল গৌণ ভার্সন এবং z হল প্যাচ ভার্সন (patch version), যা শব্দার্থিক ভার্সন পরিভাষা অনুসরণ করে হয়। অতিরিক্ত তথ্যসমূহের জন্য, দেখুন কুবারনেটিস রিলিজ ভার্সন।
কুবারনেটিস প্রজেক্ট সাম্প্রতিক তিনটি পর্যন্ত ছোট রিলিজের জন্য রিলিজ শাখা বজায় রাখে (1.35, 1.34, 1.33)। কুবারনেটিস 1.19 এবং নতুন ভার্সন আনুমানিক 1 বছরের প্যাচ সাপোর্ট পায়(patch support) কুবারনেটিস 1.18 এবং তার বেশি বয়সীরা প্রায় 9 মাস প্যাচ সাপোর্ট (patch support) পেয়েছে।
প্রযোজ্য সংশোধন, নিরাপত্তা সংশোধন সহ, তীব্রতা এবং সম্ভাব্যতার উপর নির্ভর করে, সেই তিনটি রিলিজ শাখায় ব্যাকপোর্ট করা যেতে পারে। প্যাচ রিলিজগুলি এই শাখাগুলি থেকে একটি নিয়মিত ক্যাডেন্স এ কাটা হয়, এবং প্রয়োজনে অতিরিক্ত জরুরী রিলিজগুলি।
এ রিলিজ ম্যানেজার গ্রুপ এই সিদ্ধান্তের মালিক।
আরও তথ্যের জন্য, কুবারনেটিস প্যাচ রিলিজ পৃষ্ঠাটি দেখুন।
অত্যন্ত-উপলব্ধ (HA) ক্লাস্টারে,,
নতুন এবং প্রাচীনতম kube-apiserver উদাহরণগুলি অবশ্যই একটি ছোট ভার্সনের মধ্যে থাকতে হবে৷
উদাহরণ:
kube-apiserver 1.35 এ আছেkube-apiserver ইন্সট্যান্সগুলি 1.35 এবং 1.34 এ সাপোর্টেডkubelet নতুন হওয়া উচিত নয় kube-apiserver এর চেয়ে।kubelet তিনটি ছোট ভার্সন পর্যন্ত পুরানো হতে পারে kube-apiserver এর চেয়ে (kubelet < 1.25 শুধুমাত্র দুটি ছোট ভার্সন পর্যন্ত পুরানো হতে পারে kube-apiserver এর চেয়ে).উদাহরণ:
kube-apiserver 1.35 এ আছেkubelet 1.35, 1.34,
1.33, এবং 1.32 সাপোর্টেডkube-apiserver instances in an HA cluster, this narrows the allowed kubelet versions.উদাহরণ:
kube-apiserver ইন্সট্যান্সগুলিতে 1.35 এবং 1.34 আছেkubelet 1.34, 1.33,
এবং 1.32 এ সাপোর্টেড (1.35 সাপোর্টেড নয় কারণ
এটি ভার্সন 1.34 -এ kube-apiserver ইন্সট্যান্সের চেয়ে নতুন হবে)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.35 এ আছেkube-proxy তে 1.35, 1.34,
1.33, এবং 1.32 এ সাপোর্টেডkube-apiserver instances in an HA cluster, this narrows the allowed kube-proxy versions.উদাহরণ:
kube-apiserver ইন্সট্যান্সে 1.35 এবং 1.34 আছেkube-proxy 1.34, 1.33,
এবং 1.32 এ সাপোর্টেড (1.35 সাপোর্টেড নয় কারণ
এটি ভার্সন 1.34 -এ kube-apiserver ইন্সট্যান্সের চেয়ে নতুন হবে)kube-controller-manager, kube-scheduler, এবং cloud-controller-manager নতুন হওয়া উচিত নয়
kube-apiserver থেকে ইন্সট্যান্সগুলির সাথে তারা যোগাযোগ করে। তারা kube-apiserver ক্ষুদ্র ভার্সনের সাথে মিলবে বলে আশা করা হচ্ছে,
কিন্তু একটি ছোট ভার্সন পর্যন্ত পুরানো হতে পারে (লাইভ আপগ্রেডের অনুমতি দেওয়ার জন্য)।
উদাহরণ:
kube-apiserver 1.35 এ আছেkube-controller-manager, kube-scheduler, এবং cloud-controller-manager সাপোর্টেড আছে
1.35 এবং 1.34kube-apiserver instances in an HA cluster, and these components
can communicate with any kube-apiserver instance in the cluster (for example, via a load balancer),
this narrows the allowed versions of these components.উদাহরণ:
kube-apiserver ইন্সট্যান্সে 1.35 এবং 1.34 আছেkube-controller-manager, kube-scheduler, এবং cloud-controller-manager একটি লোড ব্যালেন্সারের সাথে যোগাযোগ করে
যে কোনো kube-apiserver ইন্সট্যান্সে রুট করতে পারেkube-controller-manager, kube-scheduler, এবং cloud-controller-manager সাপোর্টেড আছে
1.34 (1.35 সাপোর্টেড নয়
কারণ এটি 1.34 ভার্সনে নতুন হবে kube-apiserver ইন্সট্যান্সের চেয়ে নতুন হবে)kubectl একটি ছোট ভার্সন (পুরানো বা নতুন) kube-apiserver এর মধ্যে সাপোর্টেড।
উদাহরণ:
kube-apiserver আছে 1.35kubectl সাপোর্টেড আছে 1.36, 1.35,
এবং 1.34kube-apiserver instances in an HA cluster, this narrows the supported kubectl versions.উদাহরণ:
kube-apiserver ইন্সট্যান্সে আছে 1.35 এবং 1.34kubectl সাপোর্টেড আছে 1.35 এবং 1.34
(অন্যান্য ভার্সনগুলি kube-apiserver উপাদানগুলির একটি থেকে একের বেশি ছোটখাট ভার্সন হবে )উপাদানগুলির মধ্যে সাপোর্টেড ভার্সনের স্কুটির প্রভাব রয়েছে যে ক্রম অনুসারে উপাদানগুলিকে আপগ্রেড করতে হবে৷ এই বিভাগটি 1.34 ভার্সন থেকে 1.35 ভার্সনে একটি বিদ্যমান ক্লাস্টার রূপান্তর করতে উপাদানগুলিকে আপগ্রেড করতে হবে তা বর্ণনা করে৷
ঐচ্ছিকভাবে, আপগ্রেড করার প্রস্তুতির সময়, কুবারনেটিস প্রজেক্ট সুপারিশ করে যে আপনি আপগ্রেড করার সময় যতটা সম্ভব রিগ্রেশন এবং বাগ ফিক্স থেকে উপকৃত হতে নিম্নলিখিতগুলি করুন:
উদাহরণস্বরূপ, আপনি যদি 1.34 ভার্সন চালাচ্ছেন, তাহলে নিশ্চিত করুন যে আপনি সাম্প্রতিক প্যাচ ভার্সনে আছেন৷ তারপর, 1.35-এর সবচেয়ে সাম্প্রতিক প্যাচ ভার্সনে আপগ্রেড করুন৷
পূর্বশর্তসমূহ:
kube-apiserver ইন্সট্যান্স হল 1.34kube-apiserver ইন্সট্যান্সগুলি 1.34 বা
1.35 এ থাকে (এটি প্রাচীনতম এবং নতুন kube-apiserver ইন্সট্যান্সের মধ্যে সর্বাধিক 1 টি ছোট ভার্সন নিশ্চিত করে )কুব-কন্ট্রোলার-ম্যানেজার, কুব-শিডিউলার এবং ক্লাউড-কন্ট্রোলার-ম্যানেজার
ইনস্ট্যান্সগুলি 1.34 ভার্সনে রয়েছে
(এটি নিশ্চিত করে যে তারা বিদ্যমান API সার্ভার ভার্সনের চেয়ে নতুন নয় ,এবং এর মধ্যে রয়েছে নতুন API সার্ভার ভার্সনের 1টি ছোট ভার্সন)kubelet ইনস্ট্যান্সগুলি 1.34 or 1.33 ভার্সনে রয়েছে
(এটি নিশ্চিত করে যে তারা বিদ্যমান API সার্ভার ভার্সনের চেয়ে নতুন নয় ,এবং নতুন API সার্ভার ভার্সনের 2টি ছোট ভার্সনের মধ্যে রয়েছে)কুবে-এপিসার্ভার ইনস্ট্যান্স যে ডেটা পাঠাবে তা পরিচালনা করতে সক্ষম:
ValidatingWebhookConfiguration এবং MutatingWebhookConfiguration অবজেক্ট অন্তর্ভুক্ত করার জন্য আপডেট করা হয়েছে
REST রিসোর্সের যেকোন নতুন ভার্সন 1.35 এ যোগ করা হয়েছে
(বা ব্যবহার করুন matchPolicy: Equivalent option v1.15+ এ সহজলভ্য)kube-apiserver আপগ্রেড করুন 1.35
kube-apiserver to not skip minor versions when upgrading, even in single-instance clusters.পূর্বশর্তসমূহ:
kube-apiserver ইনস্ট্যান্সগুলির সাথে এই উপাদানগুলি 1.35 -এ যোগাযোগ করে
(HA ক্লাস্টারে যেখানে এই কন্ট্রোল প্লেন উপাদানগুলি ক্লাস্টারের যেকোনো kube-apiserver ইনস্ট্যান্সের সাথে যোগাযোগ
করতে পারে, এই উপাদানগুলি আপগ্রেড করার আগে সমস্ত kube-apiserver ইনস্ট্যান্সগুলি আপগ্রেড করা আবশ্যক)1.35 থেকে আপগ্রেড করুন kube-controller-manager, kube-scheduler, এবং
cloud-controller-manager । kube-controller-manager, kube-scheduler,
cloud-controller-manager এর মধ্যে কোনো প্রয়োজনীয় আপগ্রেড অর্ডার নেই।
আপনি যে কোনো ক্রমে এই উপাদান আপগ্রেড করতে পারেন, বা
এমনকি একই সাথে।
পূর্বশর্তসমূহ:
kube-apiserver ইনস্ট্যান্স kubelet এর সাথে যোগাযোগ করে তা 1.35-এ।ঐচ্ছিকভাবে kubelet ইনস্ট্যান্সগুলিকে 1.35 তে আপগ্রেড করুন (অথবা সেগুলি
1.34, 1.33, বা 1.32 এ ছেড়ে দেওয়া যেতে পারে)
kubelet upgrade, drain pods from that node.
In-place minor version kubelet upgrades are not supported.kubelet instances that are persistently three minor versions behind
kube-apiserver means they must be upgraded before the control plane can be upgraded.পূর্বশর্তসমূহ:
kube-apiserver ইনস্ট্যান্স kube-proxy এর সাথে যোগাযোগ করে তা 1.35-এ।ঐচ্ছিকভাবে kube-proxy ইনস্ট্যান্সগুলিকে 1.35 তে আপগ্রেড করুন
(অথবা সেগুলি 1.34, 1.33,
বা 1.32 এ ছেড়ে দেওয়া যেতে পারে)
kube-proxy instances that are persistently three minor versions behind
kube-apiserver means they must be upgraded before the control plane can be upgraded.আপনার কুবারনেটিস সংস্করণের সাথে মেলে এমন চেঞ্জলগ (Changelog) পড়ার মাধ্যমে রিলিজ নোট পাওয়া যাবে। 1.35-এর চেঞ্জলগ দেখুন গিটহাব ।
বিকল্পভাবে, রিলিজ নোটস অনলাইনে অনুসন্ধান এবং ফিল্টার করা যেতে পারে: relnotes.k8s.io। 1.35-এর জন্য ফিল্টার করা রিলিজ নোটগুলো দেখুন relnotes.k8s.io।
"রিলিজ ম্যানেজাররা" হল একটি সার্বিক শব্দ যা কুবারনেটিসের সেই অবদানকারীদের নির্দেশ করে, যারা রিলিজ ব্রাঞ্চগুলি বজায় রাখা এবং SIG Release দ্বারা সরবরাহিত টুলগুলি ব্যবহার করে রিলিজ তৈরি করার দায়িত্বে থাকে।
প্রত্যেক ভূমিকার দায়িত্ব নীচে বর্ণিত হয়েছে।
| মেইলিং লিস্ট | স্ল্যাক | দৃশ্যমান | ব্যবহার | সদস্যতা |
|---|---|---|---|---|
| release-managers@kubernetes.io | #release-management (চ্যানেল) / @release-managers (ইউজার গ্রুপ) | পাবলিক | রিলিজ ম্যানেজারদের জন্য পাবলিক আলোচনা | সকল রিলিজ ম্যানেজার (অ্যাসোসিয়েট, এবং SIG চেয়ারস সহ) |
| release-managers-private@kubernetes.io | নেই | প্রাইভেট | স্পেশাল রিলিজ ম্যানেজারদের জন্য প্রাইভেট আলোচনা | রিলিজ ম্যানেজার, SIG রিলিজ লীডারশিপ |
| security-release-team@kubernetes.io | #security-release-team (চ্যানেল) / @security-rel-team (ইউজার গ্রুপ) | প্রাইভেট | সিকিউরিটি রেসপন্স কমিটির সাথে সিকিউরিটি রিলিজ সমন্বয় | security-discuss-private@kubernetes.io, release-managers-private@kubernetes.io |
কিছু রিলিজ সম্পর্কিত তথ্য ইম্বার্গোর অধীনে রয়েছে এবং আমরা তারা সেট করার জন্য নীতি নির্ধারণ করেছি। অধিক তথ্যের জন্য দয়া করে নিরাপত্তা ইম্বার্গো নীতি দেখুন।
লক্ষ্যস্থান: প্যাচ রিলিজ টীম এবং শাখা ম্যানেজার হ্যান্ডবুকগুলি পরের তারিখে ডিডুপ্লিকেট করা হবে।
নোট: ডকুমেন্টেশনে প্যাচ রিলিজ টিম এবং ব্রাঞ্চ ম্যানেজমেন্ট ভূমিকা সম্পর্কে উল্লেখ থাকতে পারে। এই দুই ভূমিকা রিলিজ ম্যানেজার ভূমিকায় একীভূত করা হয়েছে।
মিনিমাম প্রয়োজনীয়তা রিলিজ ম্যানেজার এবং রিলিজ ম্যানেজার অ্যাসোসিয়েটগুলির জন্য নিম্নলিখিত:
git এবং সম্পর্কিত git কমান্ড লাইন ইনভোকেশন এর মাধ্যমে
ব্রাঞ্চ সোর্স কোড ওয়ার্কফ্লো পরিচিতি।রিলিজ ম্যানেজারদের দায়িত্ব অনুসারে:
x.y.z, যেখানে z > 0)x.y.z, যেখানে z = 0)এই দলটি মাঝে মাঝে সিকিউরিটি রেসপন্স কমিটির সাথে ঘনিষ্ঠভাবে কাজ করে এবং তাই সিকিউরিটি রিলিজ প্রসেসে উল্লিখিত নির্দেশিকা মেনে চলা উচিত।
GitHub অ্যাক্সেস নিয়ন্ত্রণ: @kubernetes/release-managers
GitHub উল্লেখ: @kubernetes/release-engineering
রিলিজ ম্যানেজার হতে চাইলে, প্রথমে কাউকে রিলিজ ম্যানেজার অ্যাসোসিয়েট হিসেবে কাজ করতে হবে। অ্যাসোসিয়েটরা কয়েকটি চক্র জুড়ে রিলিজের উপর সক্রিয়ভাবে কাজ করে রিলিজ ম্যানেজারে পদোন্নতি পায়:
রিলিজ ম্যানেজার অ্যাসোসিয়েটরা হলেন রিলিজ ম্যানেজারদের শিক্ষানবিশ, যাদের আগে রিলিজ ম্যানেজার শ্যাডো হিসেবে পরিচিত করা হতো। তাদের দায়িত্ব হল:
GitHub মেনশনস: @kubernetes/release-engineering
অবদানকারীরা নিম্নলিখিত দেখানোর মাধ্যমে অ্যাসোসিয়েট হতে পারেন:
নিয়মিত অংশগ্রহণ, যার মধ্যে ৬-১২ মাসের সক্রিয় রিলিজ ইঞ্জিনিয়ারিং-সম্পর্কিত কাজ অন্তর্ভুক্ত
একটি রিলিজ চক্রে রিলিজ টিমে একজন টেকনিকাল লিড হিসেবে ভূমিকা পালনের অভিজ্ঞতা
k/release আইটেমগুলিতে কাজ করা যা Testgrid এর সাথে আমাদের ইন্টার্যাকশন এর উন্নত করে, লাইব্রেরি পরিষ্কার করা ইত্যাদি কাজে অবদান রাখা
SIG রিলিজ চেয়ারস এবং টেকনিকাল লিডস দায়ী আছেন:
তাদের এখানে স্পষ্টভাবে উল্লেখ করা হয়েছে কারণ তারা প্রতিটি ভূমিকার জন্য বিভিন্ন যোগাযোগ চ্যানেল এবং অনুমতি গ্রুপ (GitHub টিমস, GCP অ্যাক্সেস) এর মালিক। এই হিসাবে, তারা অত্যন্ত অধিকারপ্রাপ্ত কমিউনিটি সদস্য এবং কিছু ব্যক্তিগত যোগাযোগের জন্য সচেতন, যা কখনো কখনো কুবারনেটিস নিরাপত্তা প্রকাশনার সাথে সম্পর্কিত হতে পারে।
GitHub টিম: @kubernetes/sig-release-leads
পূর্ববর্তী শাখা ম্যানেজারদের তালিকা releases directory-এ kubernetes/sig-release রিপোজিটরিতে
release-x.y/release_team.md ফাইলে পাওয়া যাবে।
উদাহরণ: 1.15 Release Team