- Mockito के मुख्य मेंटेनर ने बताया कि वे मार्च 2026 तक लगभग 10 साल की मेंटेनेंस भूमिका पूरी कर लेंगे और आने वाले कुछ महीनों में धीरे-धीरे अधिकार हस्तांतरण करेंगे
- इस फैसले के सीधे कारणों में से एक के रूप में उन्होंने JVM 22 में एजेंट पॉलिसी बदलाव का ज़िक्र किया। सुरक्षा उद्देश्य वाले इस बदलाव से वे सहमत हैं, लेकिन बिना विकल्प के एकतरफा ट्रांज़िशन की मांग और ecosystem-स्तरीय विचार की कमी को बड़ा बोझ बताया
- खासकर Mockito, JVM एजेंट के सबसे बड़े उपयोगकर्ताओं में से एक होने के बावजूद, build tool support या सहयोगी चर्चा के बिना समस्या सुलझाने की ज़िम्मेदारी उसी पर आ गई, जिससे संसाधनों की थकावट और ज़िम्मेदारी का अत्यधिक बोझ पैदा हुआ
- एक अन्य कारण के रूप में उन्होंने Kotlin support की संरचनात्मक जटिलता की ओर इशारा किया और बताया कि Kotlin के JVM पर काम करने के अलग तरीके के कारण Mockito के अंदर डुप्लिकेट API और branching logic बढ़ते गए, जिससे maintenance कठिन हो गई
- हाल के समय में उन्हें Rust-आधारित web engine Servo पर काम करने में अधिक खुशी और प्रेरणा मिल रही है, और सीमित निजी समय को देखते हुए वे इस निष्कर्ष पर पहुँचे कि कर्तव्य जैसा लगने वाला volunteer maintenance work जारी रखना मुश्किल है
10 साल का माइलस्टोन और भूमिका हस्तांतरण का फैसला
- मार्च 2026 में Mockito maintenance के 10 साल पूरे होने पर उन्होंने इसे ज़िम्मेदारी हस्तांतरण के लिए एक स्वाभाविक मोड़ माना
- आने वाले कुछ महीनों में वे मौजूदा मेंटेनर के रूप में knowledge transfer और transition stabilization पर ध्यान देंगे
- अगली maintenance व्यवस्था और long-term roadmap पर चर्चा अलग GitHub issue में की जाएगी
JVM एजेंट पॉलिसी बदलाव से आई थकावट
- Mockito 5 में default artifact को JVM एजेंट में बदलने की पृष्ठभूमि JVM 22 से dynamic agent attachment को flag के पीछे छिपा देने वाली policy change है
- वे इस बदलाव के security उद्देश्य से सहमत हैं, लेकिन alternative design या migration support के बिना फैसले को लगभग तय मान लेने को समस्या बताते हैं
- Mockito लंबे समय से JVM फीचर्स के अग्रणी उपयोग के उदाहरण के रूप में इस्तेमाल होता रहा है, फिर भी इस बदलाव में collaborative feedback loop काम नहीं कर सका
- उनका आकलन है कि एजेंट के लिए build tool स्तर पर support अब भी कमज़ोर है, जो दिखाता है कि इस फीचर की प्राथमिकता कम है
- उन्होंने ज़ोर देकर कहा कि यदि स्वैच्छिक योगदान देने वाले मेंटेनर पर अत्यधिक दबाव डाला जाए तो open source collaboration structure आसानी से टूट सकती है
Kotlin support से पैदा हुआ संरचनात्मक बोझ
- वे Kotlin के प्रसार को नकारते नहीं हैं, लेकिन JVM के अंदरूनी व्यवहार में अंतर के कारण mockito-core में Kotlin-विशेष processing flow की बड़ी संख्या जुड़ गई
- suspend functions जैसी Kotlin सुविधाओं के लगातार एक जैसा काम न करने के उदाहरण हैं, जिससे API duplication और complexity बढ़ी
- नतीजतन codebase spaghetti जैसा होता गया और maintenance की कठिनाई बढ़ी, और उन्होंने साफ कहा कि इस तरह का काम उन्हें व्यक्तिगत रूप से आनंद नहीं देता
- Kotlin-केंद्रित भविष्य ने लंबे समय में Mockito maintenance के लिए उनकी प्रेरणा को कमज़ोर करने वाला कारक के रूप में काम किया
दूसरे open source कामों में फिर से मिली खुशी
- वे कई open source projects में योगदान देते रहे हैं, और हाल में Rust-आधारित web engine Servo पर काम करते हुए उन्हें विकास का आनंद फिर से महसूस हुआ
- शाम के सीमित निजी समय में Mockito की तुलना में दूसरे projects अधिक संतोष दे रहे हैं
- उन्होंने माना कि volunteer-based maintenance work का लंबे समय तक कर्तव्य जैसा महसूस होना स्वस्थ स्थिति नहीं है
फैसले की समग्र पृष्ठभूमि और संदेश
- JVM policy changes से आई निराशा, Kotlin support structure की सीमाएँ, और दूसरे projects में प्रेरणा की वापसी इस फैसले के मुख्य कारण रहे
- उन्होंने माना कि ये कारण सभी contributors पर एक समान लागू नहीं होते, और दूसरे लोग Kotlin support को अधिक उत्साह से आगे बढ़ा सकते हैं
- उन्होंने निष्कर्ष निकाला कि मेंटेनर बदलना project की long-term health के लिए अधिक फायदेमंद होगा, इसलिए वे भूमिका छोड़ेंगे
- उन्होंने open source maintenance के अनुभव को सम्मान और विशेषाधिकार बताया, और दूसरों को भी स्वैच्छिक योगदान के लिए प्रोत्साहित किया
अभी कोई टिप्पणी नहीं है.