tyler.durden/keep-a-changelog
1
0
Fork 0
mirror of https://github.com/olivierlacan/keep-a-changelog.git synced 2025-09-26 11:19:22 +02:00
Code Issues Packages Projects Releases Wiki Activity

Fix erroneous tab-indentation

Browse Source 
Should be consistently using spaces.
This commit is contained in:
Olivier Lacan 2023-03-05 16:37:27 -08:00
parent ac57cbf6e7
commit 8868e0cbeb
1 changed files with 7 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
source/fa-IR/1.0.0/index.html.haml
View File

@ -56,7 +56,7 @@ pre {direction:ltr;text-align:left}
لیست تغییرات به درد چه کسانی می‌خورد؟
%p
مصرف‌کننده‌ها، توسعه‌دهنده‌ها، کاربران نهایی و در یک کلام مردم. مسلماً وقتی نرم‌افزاری بروزرسانی می‌شود، کاربران آن دوست دارند بدانند چرا و چطور این تغییرات اعمال شده است.
مصرف‌کننده‌ها، توسعه‌دهنده‌ها، کاربران نهایی و در یک کلام مردم. مسلماً وقتی نرم‌افزاری بروزرسانی می‌شود، کاربران آن دوست دارند بدانند چرا و چطور این تغییرات اعمال شده است.
.good-practices
%h3#how
@ -133,13 +133,13 @@ pre {direction:ltr;text-align:left}
استفاده از خروجی log diff به عنوان تاریخچهٔ تغییرات
%p
استفاده از خروجی log diffها به عنوان تاریخچهٔ تغییرات، ایدهٔ بدی است. این خروجی مملو از اطلاعات درهم‌وبرهم است؛ مثلاً کامیت‌های مربوط به مرج، کامیت‌هایی با عناوین مبهم، تغییرات مربوط به مستندات و غیره.
استفاده از خروجی log diffها به عنوان تاریخچهٔ تغییرات، ایدهٔ بدی است. این خروجی مملو از اطلاعات درهم‌وبرهم است؛ مثلاً کامیت‌های مربوط به مرج، کامیت‌هایی با عناوین مبهم، تغییرات مربوط به مستندات و غیره.
%p
هدف از یک کامیت، ثبت یک گام انجام‌شده در روند تکامل سورس کد است. برخی از پروژه‌ها، کامیت‌های تمیزی دارند و برخی نه.
%p
هدف از یک مدخل جدید در فایل تاریخچهٔ تغییرات، مستندسازی شفاف تغییرات مهمِ پروژه برای کاربران نهایی است. هر مدخل در تاریخچهٔ تغییرات لزوماً متناظر با یک کامیت در تاریخچهٔ کامیت‌ها نیست. ممکن است چندین کامیت مختلف، مربوط به یک تغییر باشد و بالعکس یک کامیت (غیراستاندارد) دربردارندهٔ چندین تغییر مهم باشد.
هدف از یک مدخل جدید در فایل تاریخچهٔ تغییرات، مستندسازی شفاف تغییرات مهمِ پروژه برای کاربران نهایی است. هر مدخل در تاریخچهٔ تغییرات لزوماً متناظر با یک کامیت در تاریخچهٔ کامیت‌ها نیست. ممکن است چندین کامیت مختلف، مربوط به یک تغییر باشد و بالعکس یک کامیت (غیراستاندارد) دربردارندهٔ چندین تغییر مهم باشد.
%h4#ignoring-deprecations
%a.anchor{ href: "#ignoring-deprecations", aria_hidden: "true" }
@ -154,14 +154,14 @@ pre {direction:ltr;text-align:left}
%p
در هر نقطه‌ای از دنیا شکل نمایش تاریخ متفاوت است؛ بنابراین پیداکردن یک قالب نمایش همه‌فهم برای کل مردم دنیا کار دشواری است. مزیت استفاده از قالب‌هایی مثل <code>2017-07-17</code> این است که در آن ترتیب بزرگترین به کوچکترین واحدها یعنی سال، ماه و روز رعایت شده است. این باعث می‌شود که برخلاف برخی از قالب‌ها که در آن جای ماه و روز عوض شده، درک تاریخ دچار ابهام نشود. با درنظرگرفتن این دلایل واین واقعیت که این فرمت یک #{link_to "استاندارد ایزو", iso} است، این قالب را برای مدخل‌های تاریخچهٔ تغییرات در نظر گرفته‌ایم.
%h4#inconsistent-changes
%a.anchor{ href: "#inconsistent-changes", aria_hidden: "true" }
ناهمگونی ثبت تغییرات
Inconsistent Changes
%p
تاریخچهٔ تغییراتی که فقط شامل برخی از تغییرات است می‌تواند به اندازهٔ نبود تاریخچهٔ تغییرات خطرناک باشد. با اینکه لزومی به ثبت همهٔ تغییرات مثلاً حذف یک فاصلهٔ خالی نیست، باید هر تغییر مهمی را در تاریخچهٔ تغییرات ثبت کرد. نایکدستی در ثبت تغییرات ممکن است اعتماد کاربران را به تاریخچهٔ تغییرات به عنوان یگانه مرجع مشاهدهٔ تغییرات سلب کند. یک تاریخچهٔ تغییرات خوب باید به‌طور منظم بروزرسانی شود.
تاریخچهٔ تغییراتی که فقط شامل برخی از تغییرات است می‌تواند به اندازهٔ نبود تاریخچهٔ تغییرات خطرناک باشد. با اینکه لزومی به ثبت همهٔ تغییرات مثلاً حذف یک فاصلهٔ خالی نیست، باید هر تغییر مهمی را در تاریخچهٔ تغییرات ثبت کرد. نایکدستی در ثبت تغییرات ممکن است اعتماد کاربران را به تاریخچهٔ تغییرات به عنوان یگانه مرجع مشاهدهٔ تغییرات سلب کند. یک تاریخچهٔ تغییرات خوب باید به‌طور منظم بروزرسانی شود.
%aside
اگر فکر می‌کنید جای موارد بیشتری در این لیست خالی است با
@ -207,7 +207,7 @@ pre {direction:ltr;text-align:left}
چرا از ریلیزهای گیت‌هاب استفاده نکنیم؟
%p
ابتکار خوبی است. در هنگام انتشار #{link_to "Release", ghr}ها می‌توانید به جای عرضهٔ یک نسخهٔ ساده (مثلاً یک برچسب خالی با نام <code>v1.0.0</code>)، لیست تغییرات آن نسخه را در قالب یک یادداشت، به آن برچسب ضمیمه کنید.
%p
اما نکته این است که تاریخچهٔ تغییراتی که در هر ریلیز گیت‌هاب منتشر می‌کنید فقط در خودِ گیت‌هاب قابل استفاده است و به‌راحتی نمی‌توانید آن را به جای دیگری منتقل کنید. شاید بتوانید بسیار شبیهش کنید به نسخهٔ پیشنهادی این سند ولی کار زحمت‌داری است.