संस्करण जीवनचक्र

This page is a translated version of the page Version lifecycle and the translation is 86% complete.

Outdated translations are marked like this.

मीडियाविकि एक "सतत एकीकरण" विकास मॉडल पर काम करता है, जहाँ सॉफ़्टवेयर के बदलावों को विकिपीडिया जैसे विकिमीडिया वेबसाइटों पर नियमित रूप से लाइव प्रकाशित किया जाता है।

सिद्धांत में नए प्रमुख प्रकाशन वर्ष में दो बार प्रकाशित किए जाते हैं, और प्रकाशन की शाखाओं पर पहले प्रकाशन के बाद एक वर्ष तक सुरक्षा के अपडेट्स भेजे जाते हैं। कभी-कभार समय की कमी और कोड-आधार की संरचना में बदलाव के कारण, हम हमेशा के लिए कालग्रस्त प्रकाशनों को समर्थित नहीं कर सकते, और सुरक्षा के तथा विकट अपडेट्स कालग्रस्त स्थिति पर पहुँच चुके प्रकाशनों पर नहीं भेजे जाते हैं।

प्रकाशन प्रबंधक की सलाह है कि विकि के चालक mediawiki-announce मेलिंग सूची में सदस्यता लें जिसमें सभी प्रकाशनों की सूचनाएँ भेजी जाती हैं, और यह सुनिश्चित करें कि उनके विकि पर सॉफ़्टवेयर का यथासंभव नवीनतम संस्करण चलाया जा रहा है। ये घोषणाएँ mediawiki-l और wikitech-l पर भी पोस्ट की जाती हैं।

संस्करण और उनके जीवन का अंत

संस्करण	स्थिति	प्रकाशन	कालग्रस्त
1.44.x	भविष्य का संस्करण	जून २०२५	जून २०२६
1.43.x (LTS)	भविष्य का स्थायी समर्थन संस्करण	दिसम्बर २०२४	दिसम्बर २०२७
1.42.x	वर्तमान स्थिर संस्करण	२७ जून २०२४	जून २०२५
1.41.x	विरासती संस्करण	२१ दिसम्बर २०२३	दिसम्बर २०२४
1.40.x	कालग्रस्त संस्करण	३० जून २०२३	२८ जून २०२४
1.39.x (LTS)	वर्तमान दीर्घकालिक समर्थन संस्करण	३० नवम्बर २०२२	नवम्बर २०२५
1.38.x	कालग्रस्त संस्करण	२ जून २०२२	३० जून २०२३

ऊपर के टेबल में शामिल उन संस्करणों पर सुरक्षा के अपडेट्स भेजे नहीं जाएँगे जिन्हें कालग्रस्त घोषित किया गया है तथा जिन्हें सूचीबद्ध ही नहीं किया गया है। इनमें सुरक्षा की विकट कमज़ोरियाँ और दूसरे बग्स भी हो सकते हैं, जिनसे डेटा को नुकसान हो सकता है या फिर डेटा भ्रष्ट हो सकती है। प्रकाशन प्रबंधक ने एक दृढ़ अनुशंसा दी है कि उत्पादन के पर्यावरण में ऊपर से सिर्फ "स्थिर संस्करण", "विरासती संस्करण" या "स्थायी संस्करण" के रूप में चिह्नित संस्करणों का ही इस्तेमाल किया जाए। This also includes all versions older than the oldest version listed. They may contain critical security vulnerabilities and other major bugs, including the threat of possible data loss and/or corruption. The release manager has also issued a strong recommendation that only versions listed above as the current “stable version”, "legacy version" or “long-term support version” be used in a production environment.

MediaWiki Release Timeline

Alpha development
Release development
Stable release
Long-term support release

प्रकाशन नीति

हर छद्म-प्रकाशन में अपडेट की गई i18n फ़ाइलें और बग-सुधार मौजूद हैं। पिछले छद्म-प्रकाशनों में नई सुविधाओं को बैक-पोर्ट नहीं किया जाएगा और इसमें आम तौर पर बंडल किए गए एक्सटेंशनों और स्किन्स को शामिल नहीं किया जाता है।
प्रमुख प्रकाशन को प्रकाशित किया जाता है हर छः महीने।
छद्म-प्रकाशन (जिसमें सुरक्षा के अपडेट्स, अनुवाद के बैक-पोर्ट्स, और साधारण बग-सुधार मौजूद होते हैं) को प्रकाशित किया जाता है हर तीन महीने।
स्थायी समर्थन संस्करण (LTS: Long Term Support) को प्रकाशित किया जाता है हर दो साल। स्थायी संस्करणों के समर्थन में एक साल का ओवरलैप होता है। उदाहरणस्वरूप, 1.23 को मई 2017 तक समर्थन मिला। 1.27 को पिछले साल प्रकाशित किया गया, ताकि लोगों को बदलाव करने के एक साल पहले तक यह एक LTS के रूप में मिलती रहे।
प्रकाशन की टिप्पणियों में यह देखा जा सकता है कि क्या बदला है। क्योंकि यह एक स्वयंसेवकों द्वारा विकसित परियोजना है, यह कहना मुश्किल है कि अगले 6 से 12 महीनों में क्या होने वाला है।

संस्करण 1.36 के बाद से मीडियाविकि सिर्फ दो प्रमुख स्थायी समर्थन संस्करणों (LTS) से अपग्रेड्स को समर्थित करने पर समर्पित है (phab:T259771 देखें)। मीडियाविकि के पुराने संस्करणों से अपग्रेड करने के लिए कई चरणों का पालन करना होगा। इसका अर्थ है कि यदि आप 1.34 या उससे पहले से 1.42 में अपग्रेड करना चाहते हैं, तो पहले आपको अपने 1.34 विकि को 1.35 (या 1.39) में अपग्रेड करना होगा, और फिर 1.35 (या 1.39) से आप 1.42 में अपग्रेड कर सकेंगे।

प्रकाशन की अनुसूची

यह समयरेखा एक अनुसूची है जो बताती है कि एक नए संस्करण के प्रकाशन से पहले क्या-क्या काम होता है। प्रकाशन का असली दिनांक यहाँ पर T (प्रकाशन के "time" से) और प्रत्यय -# ("प्रकाशन से पहले के हफ़्तों की संख्या" से) के रूप में दिया गया है।

सापेक्ष अनुसूची	कार्य
T - 7	घोषित करना कि प्रकाशन की शाखा एक हफ़्ते में तैयार हो जाएगी। लोगों से यह निश्चित करने को कहना कि चालू कार्यों को पूरा करने के लिए सभी चीज़ों को उससे पहले मर्ज कर दिया जाए। Phabricator पर "MW-X.XX-release" बनाना।
T - 6	Gerrit में मूल और सभी एक्सटेंशनों के लिए शाखा बनाना।
T - 5	X.XX-rc.0 टैग लागू करें और शुरुआती प्रकाशन पात्र को प्रकाशित करना।
T - 4	बग रिपोर्ट्स को एकत्रित करना और उन्हें मेलिंग सूची में संक्षेप में दर्ज करना।
T - 3	X.XX-rc.1 टैग लागू करके द्वितीय प्रकाशन पात्र को प्रकाशित करना। जोड़ने के लिए सुझाए गए नए एक्सटेंशनों को अब तक tarball में जोड़ दिया जाना चाहिए। इसके बाद एक्सटेंशनों में कोई बदलाव नहीं किया जाता है।
T - 2	नए बग रिपोर्ट्स को इकट्ठा करना, सुधारों को मर्ज करना, गलती से जोड़ी गई नई अधूरी सुविधाओं को हटाना, X.XX-rc.2 टैग लागू करना और तीसरे पात्र को प्रकाशित करना।
T - 1	पिछला चरण दोहराना, X.XX-rc.final टैग जोड़ना और प्रकाशित करना। इसके बाद किसी भी बैकपोर्ट को समर्थित नहीं किया जाता है।
T	रिपॉज़िटरी को X.XX के साथ टैग करके प्रकाशित कर देना।

एक्सटेंशन जीवनचक्र प्रबंधन

ज़्यादातर मीडियाविकि स्थापनाओं पर कई एक्सटेंशन्स होते हैं (विकिमीडिया विकियों पर अक्सर 40 के आस-पास होते हैं)। एक्सटेंशनों को अनुरक्षित करना और उनके लिए सही संस्करण चुनना मुश्किल हो सकता है जहाँ HEAD विकास संस्करण स्थिर या पुराने स्थिर मीडियाविकि मूल में अब तक उपलब्ध न हुई सुविधाओं का इस्तेमाल करता हो। Managing the maintenance bug fixing of extensions and choosing the right version of an extension in cases where the HEAD development version relies on features not yet available in stable or oldstable MediaWiki core can be challenging.

इसलिए एक्सटेंशनों के अनुरक्षकों को मीडियाविकि संस्करण के अनुरूप हर एक्सटेंशन संस्करण के लिए गिट शाखाएँ बनाए रखने के लिए दृढ़ता से प्रोत्साहित किया जाता है। (विस्तार के लिए अनुकूलता#मीडियाविकि एक्सटेंशन्स देखें।) विकिमीडिया के गिट रिपॉज़िटरियों में होस्ट किए जाने वाले एक्सटेंशनों के लिए ये शाखाएँँ (उदाहरणस्वरूप, मीडियाविकि 1.30 के लिए REL1_30 नाम से) master से अपने आप बना दी जाती हैं जब मीडियाविकि के किसी नए संस्करण के लिए शाखा बनाई जाए (यह मान लेते हुए कि एक्सटेंशन का master हमेशा मीडियाविकि के master से अनुकूल रहेगा)। हालाँकि, एक्सटेंशन के प्रबंधक के लिए सिर्फ HEAD ही नहीं, बल्कि स्थिर और पुराने स्थिर संस्करणों में भी बग्स को ठीक कर लेना सुझाया जाता है (अगर ज़रूरत पड़े तो पुरानी शाखाओं पर सुधार को बैकपोर्ट करके)।

इन नियमों का उद्देश्य है कि मीडियाविकि को स्थापित करने वाले लोग या संगठन किसी संस्करण के नवीनतम संस्करण को स्थापित करके यह विश्वास रख पाएँ कि, उदाहरणस्वरूप गिट पर REL1_20 को सन्दर्भित करके 1.20.x मूल के लिए, वे उचित एक्सटेंशनों को आसानी से प्राप्त कर पाए। और यह गैर-प्रासंगिक और अप्रत्याशित नामों वाले tarballs और zip फ़ाइलों से आपको दूर रखता है।

ये भी देखें

Compatibility information for MediaWiki, most importantly PHP and MySQL
स्थिर इंटरफ़ेस नीति
WikiApiary पर Generators - मीडियाविकि के विभिन्न संस्करणों के उपयोग के बारे में आँकड़े।