प्रॉडक्ट की जानकारी लिखना

किसी समस्या की शिकायत करें सोर्स देखें Nightly · 7.4 . 7.3 · 7.2 · 7.1 · 7.0 · 6.5

यह दस्तावेज़, Bazel में योगदान देने वाले लोगों के लिए है.

Basel में कमिट के ब्यौरे में एक RELNOTES: टैग और एक रिलीज़ शामिल होती है नोट. Bazel टीम इसका इस्तेमाल, हर रिलीज़ में हुए बदलावों को ट्रैक करने और रिलीज़ का एलान करने के लिए करती है.

खास जानकारी

  • क्या आपका बदलाव, गड़बड़ी को ठीक करने के लिए किया गया है? ऐसे में, आपको रिलीज़ नोट की ज़रूरत नहीं पड़ती. प्लीज़ GitHub की समस्या के बारे में जानकारी दें.

  • अगर बदलाव से, उपयोगकर्ता को दिखने वाले तरीके से Bazel को जोड़ा / हटाया / बदला जाता है, तो इसके बारे में बताना फ़ायदेमंद हो सकता है.

अगर बदलाव ज़रूरी है, तो पहले डिज़ाइन दस्तावेज़ की नीति का पालन करें.

दिशा-निर्देश

रिलीज़ नोट को हमारे उपयोगकर्ता पढ़ेंगे. इसलिए, यह छोटा होना चाहिए (आदर्श रूप से एक वाक्य). इसमें, ज़्यादा जानकारी देने वाले शब्दों (Bazel के अंदर इस्तेमाल होने वाले शब्द) का इस्तेमाल नहीं करना चाहिए. साथ ही, इसमें इस बात पर फ़ोकस करना चाहिए कि बदलाव किस बारे में है.

  • ज़रूरी दस्तावेज़ का लिंक शामिल करें. आम तौर पर, सभी रिलीज़ नोट में उस फ़ाइल में एक लिंक मौजूद हो. अगर जानकारी में किसी फ़्लैग, सुविधा, किसी कमांड के नाम के बारे में बताया गया है, उपयोगकर्ता इस बारे में ज़्यादा जानना चाहेंगे.

  • कोड, सिंबल, फ़्लैग या अंडरस्कोर वाले किसी भी शब्द के चारों ओर बैककोट का इस्तेमाल करें.

  • सिर्फ़ गड़बड़ी की जानकारी कॉपी और पेस्ट न करें. ये अक्सर ऐसे होते हैं जिनका मतलब सिर्फ़ हम समझ पाते हैं और उपयोगकर्ता को समझ नहीं आता. रिलीज़ नोट ये हैं का मतलब है कि क्या बदला है और क्यों किया गया है.

  • हमेशा मौजूदा समय का इस्तेमाल करें और "Bazel अब Y के साथ काम करता है" या "X अब Z के साथ काम करता है" फ़ॉर्मैट का इस्तेमाल करें. हम नहीं चाहते कि हमारे रिलीज़ नोट, गड़बड़ी की एंट्री की तरह दिखें. सभी रिलीज़ नोट की एंट्री जानकारी देने वाली होनी चाहिए. साथ ही, उनमें एक जैसी स्टाइल और भाषा का इस्तेमाल होना चाहिए.

  • अगर किसी सुविधा को बंद कर दिया गया है या हटा दिया गया है, तो "X को बंद कर दिया गया है" या "X को हटा दिया गया है" का इस्तेमाल करें. "हटाया गया" नहीं या "हटा दिया गया है."

  • अगर Bazel अब कुछ अलग तरीके से काम करता है, तो "X अब $oldBehavior के बजाय $newBehavior का इस्तेमाल करता है" का इस्तेमाल करें. इससे उपयोगकर्ता को यह पता चलता है कि उसे कि वे नई रिलीज़ का इस्तेमाल कब करेंगे.

  • अगर Basel अब काम करता है या अब किसी सुविधा के साथ काम नहीं करता, तो "Bazu अब काम करता है" का इस्तेमाल करें / अब X के साथ काम नहीं करता".

  • इस बारे में जानकारी दें कि क्यों कुछ हटा दिया गया है / काम नहीं कर रहा है / उसमें बदलाव क्यों किया गया है. एक वाक्य है लेकिन हम चाहते हैं कि उपयोगकर्ता उनके निर्माण पर पड़ने वाले प्रभाव का मूल्यांकन कर सकें.

  • आने वाले समय में मिलने वाले फ़ंक्शन के बारे में कोई वादा न करें. "यह फ़्लैग हटा दिया जाएगा" या "इसमें बदलाव किया जाएगा" जैसे वाक्यों का इस्तेमाल न करें. इससे अनिश्चितता पैदा होती है. उपयोगकर्ता सबसे पहले यह जानना चाहेगा कि "कब?" और हम नहीं चाहते कि वह किसी अनजान समय पर, अपने मौजूदा बिल्ड के काम न करने की चिंता करे.

प्रोसेस

रिलीज़ के भाग के रूप में प्रोसेस, हम हर प्रतिबद्धता के लिए RELNOTES टैग इकट्ठा करते हैं. हम हर चीज़ को Google की दस्तावेज़ जहां हम नोट की समीक्षा करते हैं, उनमें बदलाव करते हैं, और उन्हें व्यवस्थित करते हैं.

रिलीज़ मैनेजर, bazel-dev की मेलिंग-लिस्ट पर एक ईमेल भेजता है. Bazel के योगदान देने वालों को दस्तावेज़ में योगदान देने का न्योता दिया गया है. साथ ही, यह पक्का करने के लिए कहा गया है कि उनके बदलाव, एलान में सही तरीके से दिखें.

बाद में, bazel-blog रिपॉज़िटरी का इस्तेमाल करके, Bazel के ब्लॉग पर यह सूचना सबमिट की जाएगी.