خطة الإصدار

From The Document Foundation Wiki
Jump to navigation Jump to search
This page is a translated version of the page ReleasePlan and the translation is 56% complete.
Other languages:
Bahasa Indonesia • ‎Deutsch • ‎English • ‎dansk • ‎español • ‎français • ‎italiano • ‎português do Brasil • ‎română • ‎русский • ‎العربية • ‎فارسی • ‎日本語

مقدمة

لقد أظهرت مسارات الإصدار المستندة إلى الوقت بأنها تُنتِج برمجيات حرّة بأفضل نوعية. الإصدار المستند إلى الوقت هو ذلك الذي لا ينتظر أية ميزات، أو إصلاحات عيوب - لكنه يستند (بأنقى ما يمكن) إلى الوقت. هذا يُلزم بالإنضباط في تقديم الإصلاحات، يعطي استباقية، ويسمح بعملية إصدار أكثر انتظاماً. وهي أيضا الوضعية التي بالضرورة تجعلنا نُصدِر بصورة مبكرة، ومن ثم أسرع، وبصورة متنامية مصلحين عيوب الإصدارات استناداً إلى الإصدار المستقر السابق. وهكذا إذا كانت لديك الحاجة إلى الإصدار ذي المستوى الأعلى نوعية، فإن مما يجعل في الأمر مغزى هو إرجاء الإنتقال لحين إصدار النقطة الثانوية الأولى أو ربما الثانية.

  • يقوم ليبر بإصدارات متوقَّعة نصف سنوية والتي تكون في تزامن مع مشاريع البرمجيات الحرة الأخرى (مثلا گنوم Gnome) وهي تتقدم شهراً على الأقل عن إصدارات لينكس الرئيسية.
  • Synchronizing time-based release schedule with the wider Free Software ecosystem also has huge advantages, by getting our new features, out to users as quickly as possible – with a minimum of distribution cycle lag. In consequence, we aim at six monthly releases, and over time nudge them to align well with the March/September norms.
  • Time-based release trains have been shown to produce the best quality Free software. A time based release is one that does not wait for either features, or bug fixes - but is based (as purely as possible) on time. This enforces discipline in introducing fixes, gives predictability, and allows more regular releasing. It is also the case that we will necessarily release earlier, and then rapidly, incrementally bug fix releases based on the previous stable version. Thus if you have a need for the very highest quality version, it can make sense to defer a move until the first or perhaps second minor point release.
  • There are 2 branches: Fresh (the newest release) and Still (the previous release), which are intended for mainstream feature users and conservative, corporate deployments respectively.
  • As a result, users get new major version every six months with a wide range of features, fixes, and enhancements. In addition, they get many pure bugfix micro releases. The first X.Y.0 release is intended for early adopters. More conservative users are advised to wait for a later X.Y.Z bugfix release.

Note that the dates mentioned in the schedule might get shifted if there are serious technical or other problems with the release. An extra RC might be needed if the final release candidate does not fit the Release Criteria. Such problem would shift the final release by one week or even more. Template:LibOReleaseLifecycle/ar

الإصدار 7.1

تواريخ أساسية للإصدارات الأولية وإصدارات إصلاح العيوب
الإصدار التجميد النشر
7.1.0 (التجميد: الأسبوع 02) Week 43 , أكتوبر ١٩, ٢٠٢٠ - أكتوبر ٢٥, ٢٠٢٠ Week 05 , فبراير ١, ٢٠٢١ - فبراير ٧, ٢٠٢١
7.1.1 Week 06 , فبراير ٨, ٢٠٢١ - فبراير ١٤, ٢٠٢١ Week 09 , مارس ١, ٢٠٢١ - مارس ٧, ٢٠٢١
7.1.2 Week 10 , مارس ٨, ٢٠٢١ - مارس ١٤, ٢٠٢١ Week 13 , مارس ٢٩, ٢٠٢١ - أبريل ٤, ٢٠٢١
7.1.3 Week 15 , أبريل ١٢, ٢٠٢١ - أبريل ١٨, ٢٠٢١ Week 18 , مايو ٣, ٢٠٢١ - مايو ٩, ٢٠٢١
7.1.4 Week 20 , مايو ١٧, ٢٠٢١ - مايو ٢٣, ٢٠٢١ Week 23 , يونيو ٧, ٢٠٢١ - يونيو ١٣, ٢٠٢١
7.1.5 Week 26 , يونيو ٢٨, ٢٠٢١ - يوليو ٤, ٢٠٢١ Week 29 , يوليو ١٩, ٢٠٢١ - يوليو ٢٥, ٢٠٢١
7.1.6 Week 33 , أغسطس ١٦, ٢٠٢١ - أغسطس ٢٢, ٢٠٢١ Week 36 , سبتمبر ٦, ٢٠٢١ - سبتمبر ١٢, ٢٠٢١
7.1.7 Week 41 , أكتوبر ١١, ٢٠٢١ - أكتوبر ١٧, ٢٠٢١ Week 44 , نوفمبر ١, ٢٠٢١ - نوفمبر ٧, ٢٠٢١
نهاية الحياة تشرين الثاني 30، 2021

انظر أيضاً الجدول التفصيلي و ملاحظات الإصدار.


الإصدار 7.0

التواريخ الأساسية للإصدارات البدائية وإصدارات إصلاح العيوب
الاصدار التجميد النشر
7.0.0 (التجميد: الأسبوع 29) Week 19 , مايو ٤, ٢٠٢٠ - مايو ١٠, ٢٠٢٠ Week 32 , أغسطس ٣, ٢٠٢٠ - أغسطس ٩, ٢٠٢٠
7.0.1 Week 33 , أغسطس ١٠, ٢٠٢٠ - أغسطس ١٦, ٢٠٢٠ Week 36 , أغسطس ٣١, ٢٠٢٠ - سبتمبر ٦, ٢٠٢٠
7.0.2 Week 38 , سبتمبر ١٤, ٢٠٢٠ - سبتمبر ٢٠, ٢٠٢٠ Week 41 , أكتوبر ٥, ٢٠٢٠ - أكتوبر ١١, ٢٠٢٠
7.0.3 Week 43 , أكتوبر ١٩, ٢٠٢٠ - أكتوبر ٢٥, ٢٠٢٠ Week 46 , نوفمبر ٩, ٢٠٢٠ - نوفمبر ١٥, ٢٠٢٠
7.0.4 Week 48 , نوفمبر ٢٣, ٢٠٢٠ - نوفمبر ٢٩, ٢٠٢٠ Week 51 , ديسمبر ١٤, ٢٠٢٠ - ديسمبر ٢٠, ٢٠٢٠
7.0.5 Week 07 , فبراير ١٥, ٢٠٢١ - فبراير ٢١, ٢٠٢١ Week 10 , مارس ٨, ٢٠٢١ - مارس ١٤, ٢٠٢١
7.0.6 Week 16 , أبريل ١٩, ٢٠٢١ - أبريل ٢٥, ٢٠٢١ Week 19 , مايو ١٠, ٢٠٢١ - مايو ١٦, ٢٠٢١
نهاية الحياة 31 أيار 2021

انظر أيضاً الجدول التفصيلي و ملاحظات الإصدار.

الإصدار 6.4

التواريخ الأساسية للإصدارات البدائية وإصدارات إصلاح العيوب
الاصدار التجميد النشر
6.4.0 (التجميد: الأسبوع 02) Week 42 , أكتوبر ١٤, ٢٠١٩ - أكتوبر ٢٠, ٢٠١٩ Week 05 , يناير ٢٧, ٢٠٢٠ - فبراير ٢, ٢٠٢٠
6.4.1 Week 06 , فبراير ٣, ٢٠٢٠ - فبراير ٩, ٢٠٢٠ Week 09 , فبراير ٢٤, ٢٠٢٠ - مارس ١, ٢٠٢٠
6.4.2 Week 09 , فبراير ٢٤, ٢٠٢٠ - مارس ١, ٢٠٢٠ Week 12 , مارس ١٦, ٢٠٢٠ - مارس ٢٢, ٢٠٢٠
6.4.3 Week 13 , مارس ٢٣, ٢٠٢٠ - مارس ٢٩, ٢٠٢٠ Week 16 , أبريل ١٣, ٢٠٢٠ - أبريل ١٩, ٢٠٢٠
6.4.4 Week 18 , أبريل ٢٧, ٢٠٢٠ - مايو ٣, ٢٠٢٠ Week 21 , مايو ١٨, ٢٠٢٠ - مايو ٢٤, ٢٠٢٠
6.4.5 Week 24 , يونيو ٨, ٢٠٢٠ - يونيو ١٤, ٢٠٢٠ Week 27 , يونيو ٢٩, ٢٠٢٠ - يوليو ٥, ٢٠٢٠
6.4.6 Week 30 , يوليو ٢٠, ٢٠٢٠ - يوليو ٢٦, ٢٠٢٠ Week 33 , أغسطس ١٠, ٢٠٢٠ - أغسطس ١٦, ٢٠٢٠
6.4.7 Week 39 , سبتمبر ٢١, ٢٠٢٠ - سبتمبر ٢٧, ٢٠٢٠ Week 42 , أكتوبر ١٢, ٢٠٢٠ - أكتوبر ١٨, ٢٠٢٠
نهاية الحياة 30 تشرين الثاني 2020

انظر أيضاً الجدول التفصيلي و ملاحظات الإصدار.

الإصدار 6.3

التواريخ الأساسية للإصدارات البدائية وإصدارات إصلاح العيوب
الاصدار التجميد النشر
6.3.0 (التجميد: الأسبوع 29) Week 19 , مايو ٦, ٢٠١٩ - مايو ١٢, ٢٠١٩ Week 32 , أغسطس ٥, ٢٠١٩ - أغسطس ١١, ٢٠١٩
6.3.1 Week 32 , أغسطس ٥, ٢٠١٩ - أغسطس ١١, ٢٠١٩ Week 35 , أغسطس ٢٦, ٢٠١٩ - سبتمبر ١, ٢٠١٩
6.3.2 Week 36 , سبتمبر ٢, ٢٠١٩ - سبتمبر ٨, ٢٠١٩ Week 39 , سبتمبر ٢٣, ٢٠١٩ - سبتمبر ٢٩, ٢٠١٩
6.3.3 Week 41 , أكتوبر ٧, ٢٠١٩ - أكتوبر ١٣, ٢٠١٩ Week 44 , أكتوبر ٢٨, ٢٠١٩ - نوفمبر ٣, ٢٠١٩
6.3.4 Week 47 , نوفمبر ١٨, ٢٠١٩ - نوفمبر ٢٤, ٢٠١٩ Week 50 , ديسمبر ٩, ٢٠١٩ - ديسمبر ١٥, ٢٠١٩
6.3.5 Week 05 , يناير ٢٧, ٢٠٢٠ - فبراير ٢, ٢٠٢٠ Week 08 , فبراير ١٧, ٢٠٢٠ - فبراير ٢٣, ٢٠٢٠
6.3.6 Week 15 , أبريل ٦, ٢٠٢٠ - أبريل ١٢, ٢٠٢٠ Week 18 , أبريل ٢٧, ٢٠٢٠ - مايو ٣, ٢٠٢٠
نهاية الحياة 29 أيار 2020

انظر أيضاً الجدول التفصيلي و ملاحظات الإصدار.

التواريخ

The release is time-based but the schedule defines calendar weeks instead of exact dates. It is because we are always a bit flexible. The release can be delayed by few days because of blocker bugs, build problems, and other technical issues.

The release consists of several beta and release candidate builds. There are needed several actions for each build. The ideal workflow looks like:

  • Monday: commit deadline; reminder is sent to devel, l10n mailing list before it happens
  • Tuesday: the tag is created on a commit that builds and passes unit-, subsequent-, and smoke-tests; tag is announced on the devel and qa mailing lists
  • Wednesday: builds are uploaded on the early pre-release site; they are announced on the devel and qa mailing lists
  • Thursday: builds are uploaded on mirrors. They are announced via many channels, e.g. mailing lists, twitter
  • Friday: builds are available via the official pre-release site

The final release is usually announced on Thursday, few days after the final release candidate is out.

Note that we are very strict about commits to the final release candidate, so full regression test is not needed. It is used as the final build when it passes the needed tests. It is just renamed on mirrors.

Schedule

The schedule is based on the following rules:

  • do the major release every six months and synchronize it (at least one month ahead) with major Linux distributions; it always comes with a wide range of features, fixes, and enhancements
  • do a pure bugfix release every month after the main release until it is good enough even for the most conservative people; do it less frequently afterwards
  • do pure bugfix releases, including security fixes, until the next release is ready for most conservative people
  • do not do two builds the same week.

The result is the following template:

Interlocking releases
حدث صيف شتاء
x.y feature freeze Jun(ب) Dec(ب)
x.y.0 first release Aug(ب) Feb(ب)
x.y.1 bugfix release Sep(ب) Mar(ب)
x.y.2 bugfix release Oct(ب) Apr(ب)
x.y.3 bugfix release Nov(ب) May(ب)
x.y.4 bugfix release Dec(ب) Jun(ب)
x.y.5 bugfix release Feb(م) Aug(م)
x.y.6 bugfix release Apr(م) Oct(م)

حيث (ب) يعني بداية الشهر، (م) يعني منتصف الشهر و (ه) يعني نهاية الشهر.

String freeze

The release plans for the first version of each major release indicate a "hard English string & UI freeze". The idea is to make the lives of translators easier. The translators should be able to trust that no new translatable strings are added into the UI or Help files between the period of the string freeze and release.

After the first version of a major release is out, correcting mistakes in the UI and Help strings is fine. Any completely new content should target the next major release.

Version scheme

We do several builds around each release. The following versioning scheme is used:

  • X.Y.0.0.alphaZ - Zth alpha version of the initial release
  • X.Y.0.0.betaZ - Zth beta version of the initial release
  • X.Y.0.Z - Zth release candidate of the initial release, last rc is considered as final and put on the main download page
  • X.Y.1.Z - Zth release candidate of the 1st bugfix release, last rc is considered as final and put on the main download page

It seems to be the best compromise with the following advantages:

  • easy to understand for normal users, alpha, beta flags are known from other projects, so they set reasonable expectations
  • correct alphabetical sorting in RPM, Bugzilla
  • “easy” to parse (alpha/beta strings delimited by dot)

There was a long discussion about this scheme on the mailing list.

Accelerating the release cycle

This acceleration of the release cycle involves some considerable release engineering and QA effort. To reduce the cost of these, we work to provide complete (ie. containing all languages) daily snapshots of the master branch to allow continual testing of code improvements. This works partially already, as can be seen/downloaded from here.

Similarly, we plan to increasingly automate the build process to allow a much lower-touch release flow, and to continue to shrink the footprint of our binaries to allow far more rapid transfer of product-equivalent builds.

End-of-Life Releases

A release normally has a lifetime of around nine months. We consider a release to have reached its End of Life (EOL) one month after the last planned release.

If you want longer term support for a release, you’re encouraged to engage any certified L3 provider who could provide you with the service.

Because of the amount of data, the releases were split out to ReleasePlan/Archive.