འགྲེམ་སྤེལ་ལས་འཆར།
TDF LibreOffice Document Liberation Project Community Blogs Weblate Nextcloud Redmine Ask LibreOffice Donate
ངོ་སྤྲོད།
དུས་ཐོག་གི་མཉེན་ཆས་འགྲེམས་སྤེལ་གྱིས་རིན་མེད་མཉེན་ཆས་སྤུས་ལེགས་བཟོ་ཐུབ་པའི་ར་སྤྲོད་བྱུང་ཡོད། དུས་ཐོག་གི་མཉེན་ཆས་འགྲེམས་སྤེལ་ནི་ཁྱད་ཆོས་སམ་སྐྱོན་བཅོས་སོགས་ལ་མི་སྒུག་པར། དུས་ཚོད་ལ་གཞི་བཅོལ་ནས་བྱུང་བ་ཞིག་ཡིན། འདིས་སྐྱོན་བཅོས་ངོ་སྤྲོད་བྱེད་པར་སྒྲིག་ལམ་བཙན་པོ་བཟོ་བ་དང་། སྔོན་དཔག་ཐུབ་པའི་མཐུན་རྐྱེན་སྐྲུན་པ། རྒྱུན་ལྡན་གྱི་མཉེན་ཆས་འགྲེམས་སྤེལ་མང་ཙམ་བྱེད་དུ་འཇུག་པ་ཡིན། ད་དུང་ང་ཚོས་ངེས་པར་དུ་མཉེན་ཆས་འགྲེམས་སྤེལ་སྔ་ཙམ་བྱས་ནས་སྐྱོན་བཅོས་གསར་པ་རྣམས་མྱུར་དུ་འགྲེམས་སྤེལ་བྱེད་དགོས་པའི་གནས་སྟངས་ཀྱང་ཡོད། དེས་ན། གལ་སྲིད་ཁྱེད་ལ་སྤུས་ཚད་ཤིན་ཏུ་མཐོ་བའི་མཉེན་ཆས་ཀྱི་ཐོན་རིམ་དེ་དགོས་ན། མཉེན་ཆས་གསར་ཐོན་རིམ་པ་དང་པོ་འམ་གཉིས་པའི་བར་ཕྱིར་འགྱངས་གནང་ན་དགེ་མཚན་ཆེ།
རིན་མེད་ཡིག་ཚང་མཉེན་ཆས་ཀྱིས་ལོ་གཉིས་རེར། གྣོམ་ (Gnome) ལྟ་བུའི་རིན་མེད་མཉེན་ཆས་ཀྱི་ལས་འཆར་རྣམས་དང་དུས་ཚོད་མཉམ་བསྒྲིགས་ཀྱིས་སྔོན་དཔགས་འགྲེམ་སྤེལ་བྱེད་ཀྱིན་ཡོད་ལ། ཆེ་ཁག་ལི་ནཀྶ་ (Linux) འགྲེམ་སྤེལ་དག་ལས་ཉུང་མཐར་ཟླ་བ་གཅིག་གིས་སྔ་ཡི་ཡོད།
- Synchronising the time-based release schedule with the wider Free Software ecosystem also has huge benefits in getting our new features out to users as quickly as possible, with a minimum of lag in the distribution cycle. As a result, we are aiming for six monthly releases, in February and August.
- There are two versions available: the latest release for technology enthusiasts, early adopters and power users, and the previous release - with fewer features but tested for longer - for corporate implementations and more cautious users.
- As a result, users get a new major release every six months with a wide range of features, fixes and enhancements. They will also receive many bug-fixing 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.3/X.Y.4 bugfix release.
Note that the dates in this schedule may change if there are serious technical or other problems with the release. An extra RC might be needed if the final release candidate has a catastrophic problem. Such a problem could delay the final release by a week or more. The decision should be made at a meeting of the Engineering Steering Committee.
The simplified graphic below shows three releases placed on a timeline consisting of 24 months.
འགྲེམ་སྤེལ་ཐོན་རིམ། ༢༤.༢
| འགྲེམ་སྤེལ་ཐོན་རིམ། | བཀག་སྐྱིལ། | ཁྱབ་སྤེལ། |
|---|---|---|
| 24.2.0 བཀག་སྐྱིལཿ གཟའ་འཁོར། ༠༢ | Week 47 , ཟླ་བཅུ་གཅིག་པ། ༢༠, ༢༠༢༣ - ཟླ་བཅུ་གཅིག་པ། ༢༦, ༢༠༢༣ | Week 05 , ཟླ་བ་དང་པོ། ༢༩, ༢༠༢༤ - ཟླ་བ་གཉིས་པ། ༤, ༢༠༢༤ |
| 24.2.1 | Week 06 , ཟླ་བ་གཉིས་པ། ༥, ༢༠༢༤ - ཟླ་བ་གཉིས་པ། ༡༡, ༢༠༢༤ | Week 09 , ཟླ་བ་གཉིས་པ། ༢༦, ༢༠༢༤ - ཟླ་བ་གསུམ་པ། ༣, ༢༠༢༤ |
| 24.2.2 | Week 10 , ཟླ་བ་གསུམ་པ། ༤, ༢༠༢༤ - ཟླ་བ་གསུམ་པ། ༡༠, ༢༠༢༤ | Week 13 , ཟླ་བ་གསུམ་པ། ༢༥, ༢༠༢༤ - ཟླ་བ་གསུམ་པ། ༣༡, ༢༠༢༤ |
| 24.2.3 | Week 15 , ཟླ་བཞི་བ། ༨, ༢༠༢༤ - ཟླ་བཞི་བ། ༡༤, ༢༠༢༤ | Week 18 , ཟླ་བཞི་བ། ༢༩, ༢༠༢༤ - ཟླ་ལྔ་བ། ༥, ༢༠༢༤ |
| 24.2.4 | Week 20 , ཟླ་ལྔ་བ། ༡༣, ༢༠༢༤ - ཟླ་ལྔ་བ། ༡༩, ༢༠༢༤ | Week 23 , ཟླ་དྲུག་པ། ༣, ༢༠༢༤ - ཟླ་དྲུག་པ། ༩, ༢༠༢༤ |
| 24.2.5 | Week 26 , ཟླ་དྲུག་པ། ༢༤, ༢༠༢༤ - ཟླ་དྲུག་པ། ༣༠, ༢༠༢༤ | Week 29 , ཟླ་བདུན་པ། ༡༥, ༢༠༢༤ - ཟླ་བདུན་པ། ༢༡, ༢༠༢༤ |
| 24.2.6 | Week 33 , ཟླ་བརྒྱད་པ། ༡༢, ༢༠༢༤ - ཟླ་བརྒྱད་པ། ༡༨, ༢༠༢༤ | Week 36 , ཟླ་དགུ་བ། ༢, ༢༠༢༤ - ཟླ་དགུ་བ། ༨, ༢༠༢༤ |
| 24.2.7 | Week 41 , ཟླ་བཅུ་བ། ༧, ༢༠༢༤ - ཟླ་བཅུ་བ། ༡༣, ༢༠༢༤ | Week 44 , ཟླ་བཅུ་བ། ༢༨, ༢༠༢༤ - ཟླ་བཅུ་གཅིག་པ། ༣, ༢༠༢༤ |
| དུས་རྫོགས། | ཕྱི་ཟླ་ ༡༡ ཚེས་ ༣༠ ཕྱི་ལོ་ ༢༠༢༤ | |
See also the detailed schedule and the release notes.
འགྲེམ་སྤེལ་ཐོན་རིམ། ༧.༦
| འགྲེམ་སྤེལ་ཐོན་རིམ། | བཀག་སྐྱིལ། | ཁྱབ་སྤེལ། |
|---|---|---|
| 7.6.0 བཀག་སྐྱིལཿ གཟའ་འཁོར། ༣༠ | Week 19 , ཟླ་ལྔ་བ། ༨, ༢༠༢༣ - ཟླ་ལྔ་བ། ༡༤, ༢༠༢༣ | Week 34 , ཟླ་བརྒྱད་པ། ༢༡, ༢༠༢༣ - ཟླ་བརྒྱད་པ། ༢༧, ༢༠༢༣ |
| 7.6.1 | Week 34 , ཟླ་བརྒྱད་པ། ༢༡, ༢༠༢༣ - ཟླ་བརྒྱད་པ། ༢༧, ༢༠༢༣ | Week 37 , ཟླ་དགུ་བ། ༡༡, ༢༠༢༣ - ཟླ་དགུ་བ། ༡༧, ༢༠༢༣ |
| 7.6.2 | Week 38 , ཟླ་དགུ་བ། ༡༨, ༢༠༢༣ - ཟླ་དགུ་བ། ༢༤, ༢༠༢༣ | Week 39 , ཟླ་དགུ་བ། ༢༥, ༢༠༢༣ - ཟླ་བཅུ་བ། ༡, ༢༠༢༣ |
| 7.6.3 | Week 44 , ཟླ་བཅུ་བ། ༣༠, ༢༠༢༣ - ཟླ་བཅུ་གཅིག་པ། ༥, ༢༠༢༣ | Week 47 , ཟླ་བཅུ་གཅིག་པ། ༢༠, ༢༠༢༣ - ཟླ་བཅུ་གཅིག་པ། ༢༦, ༢༠༢༣ |
| 7.6.4 | Week 50 , ཟླ་བཅུ་གཉིས་པ། ༡༡, ༢༠༢༣ - ཟླ་བཅུ་གཉིས་པ། ༡༧, ༢༠༢༣ | Week 53 , ཟླ་བ་དང་པོ། ༡, ༢༠༢༤ - ཟླ་བ་དང་པོ། ༧, ༢༠༢༤ |
| 7.6.5 | Week 05 , ཟླ་བ་དང་པོ། ༢༩, ༢༠༢༤ - ཟླ་བ་གཉིས་པ། ༤, ༢༠༢༤ | Week 08 , ཟླ་བ་གཉིས་པ། ༡༩, ༢༠༢༤ - ཟླ་བ་གཉིས་པ། ༢༥, ༢༠༢༤ |
| 7.6.6 | Week 10 , ཟླ་བ་གསུམ་པ། ༤, ༢༠༢༤ - ཟླ་བ་གསུམ་པ། ༡༠, ༢༠༢༤ | Week 13 , ཟླ་བ་གསུམ་པ། ༢༥, ༢༠༢༤ - ཟླ་བ་གསུམ་པ། ༣༡, ༢༠༢༤ |
| 7.6.7 | Week 16 , ཟླ་བཞི་བ། ༡༥, ༢༠༢༤ - ཟླ་བཞི་བ། ༢༡, ༢༠༢༤ | Week 19 , ཟླ་ལྔ་བ། ༦, ༢༠༢༤ - ཟླ་ལྔ་བ། ༡༢, ༢༠༢༤ |
| དུས་རྫོགས། | ཕྱི་ཟླ་ ༠༦ ཚེས་ ༡༢ ཕྱི་ལོ་ ༢༠༢༤ | |
ཞིབ་ཕྲའི་དུས་ཚོད་རེའུ་མིག་དང་། འགྲེམ་སྤེལ་གསལ་བཤད་ལའང་གཟིགས།
འགྲེམ་སྤེལ་ཐོན་རིམ། ༧.༥
| འགྲེམ་སྤེལ་ཐོན་རིམ། | བཀག་སྐྱིལ། | ཁྱབ་སྤེལ། |
|---|---|---|
| 7.5.0 བཀག་སྐྱིལཿ གཟའ་འཁོར། ༠༢ | Week 47 , ཟླ་བཅུ་གཅིག་པ། ༢༡, ༢༠༢༢ - ཟླ་བཅུ་གཅིག་པ། ༢༧, ༢༠༢༢ | Week 05 , ཟླ་བ་དང་པོ། ༣༠, ༢༠༢༣ - ཟླ་བ་གཉིས་པ། ༥, ༢༠༢༣ |
| 7.5.1 | Week 06 , ཟླ་བ་གཉིས་པ། ༦, ༢༠༢༣ - ཟླ་བ་གཉིས་པ། ༡༢, ༢༠༢༣ | Week 09 , ཟླ་བ་གཉིས་པ། ༢༧, ༢༠༢༣ - ཟླ་བ་གསུམ་པ། ༥, ༢༠༢༣ |
| 7.5.2 | Week 10 , ཟླ་བ་གསུམ་པ། ༦, ༢༠༢༣ - ཟླ་བ་གསུམ་པ། ༡༢, ༢༠༢༣ | Week 13 , ཟླ་བ་གསུམ་པ། ༢༧, ༢༠༢༣ - ཟླ་བཞི་བ། ༢, ༢༠༢༣ |
| 7.5.3 | Week 15 , ཟླ་བཞི་བ། ༡༠, ༢༠༢༣ - ཟླ་བཞི་བ། ༡༦, ༢༠༢༣ | Week 18 , ཟླ་ལྔ་བ། ༡, ༢༠༢༣ - ཟླ་ལྔ་བ། ༧, ༢༠༢༣ |
| 7.5.4 | Week 20 , ཟླ་ལྔ་བ། ༡༥, ༢༠༢༣ - ཟླ་ལྔ་བ། ༢༡, ༢༠༢༣ | Week 23 , ཟླ་དྲུག་པ། ༥, ༢༠༢༣ - ཟླ་དྲུག་པ། ༡༡, ༢༠༢༣ |
| 7.5.5 | Week 26 , ཟླ་དྲུག་པ། ༢༦, ༢༠༢༣ - ཟླ་བདུན་པ། ༢, ༢༠༢༣ | Week 29 , ཟླ་བདུན་པ། ༡༧, ༢༠༢༣ - ཟླ་བདུན་པ། ༢༣, ༢༠༢༣ |
| 7.5.6 | Week 33 , ཟླ་བརྒྱད་པ། ༡༤, ༢༠༢༣ - ཟླ་བརྒྱད་པ། ༢༠, ༢༠༢༣ | Week 36 , ཟླ་དགུ་བ། ༤, ༢༠༢༣ - ཟླ་དགུ་བ། ༡༠, ༢༠༢༣ |
| 7.5.7 | Week 38 , ཟླ་དགུ་བ། ༡༨, ༢༠༢༣ - ཟླ་དགུ་བ། ༢༤, ༢༠༢༣ | Week 39 , ཟླ་དགུ་བ། ༢༥, ༢༠༢༣ - ཟླ་བཅུ་བ། ༡, ༢༠༢༣ |
| 7.5.8 | Week 41 , ཟླ་བཅུ་བ། ༩, ༢༠༢༣ - ཟླ་བཅུ་བ། ༡༥, ༢༠༢༣ | Week 44 , ཟླ་བཅུ་བ། ༣༠, ༢༠༢༣ - ཟླ་བཅུ་གཅིག་པ། ༥, ༢༠༢༣ |
| དུས་རྫོགས། | ཕྱི་ཟླ་ ༡༡ ཚེས་ ༣༠ ཕྱི་ལོ་ ༢༠༢༣ | |
ཞིབ་ཕྲའི་དུས་ཚོད་རེའུ་མིག་དང་། འགྲེམ་སྤེལ་གསལ་བཤད་ལའང་གཟིགས།
ཚེས་གྲངས།
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.
ལས་དུས་རེའུ་མིག
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:
| མཛད་རིམ། | དབྱར་དུས། | དགུན་དུས། |
|---|---|---|
| x.y feature freeze | ཟླ་བ་དྲུག་པ།(b) | ཟླ་བ་བཅུ་གཉིས་པ།(b) |
| x.y.0 འགྲེམ་སྤེལ་དང་པོ། | ཟླ་བ་བརྒྱད་པ།(b) | ཟླ་བ་གཉིས་པ།(b) |
| x.y.1 སྐྱོན་སེལ་འགྲེམ་སྤེལ། | ཟླ་བ་དགུ་པ།(b) | ཟླ་བ་གསུམ་པ།(b) |
| x.y.2 སྐྱོན་སེལ་འགྲེམ་སྤེལ། | ཟླ་བ་བཅུ་པ།(b) | ཟླ་བ་བཞི་པ།(b) |
| x.y.3 སྐྱོན་སེལ་འགྲེམ་སྤེལ། | ཟླ་བ་བཅུ་གཅིག་པ།(b) | ཟླ་བ་ལྔ་པ།(b) |
| x.y.4 སྐྱོན་སེལ་འགྲེམ་སྤེལ། | ཟླ་བ་བཅུ་གཉིས་པ།(b) | ཟླ་བ་དྲུག་པ།(b) |
| x.y.5 སྐྱོན་སེལ་འགྲེམ་སྤེལ། | ཟླ་བ་གཉིས་པ།(m) | ཟླ་བ་བརྒྱད་པ།(m) |
| x.y.6 སྐྱོན་སེལ་འགྲེམ་སྤེལ། | ཟླ་བ་བཞི་པ།(m) | ཟླ་བ་བཅུ་པ།(m) |
Where (b) means the beginning of the month, (m) means the middle of the month and (e) means the end of the month.
ཡིག་རྟགས་བཀག་སྐྱིལ།
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.
In practice, you should keep an eye on the tagging of the first release candidate. One way to find out, if RC1 has been tagged is to visit the tag view of the LibreOffice core repository in Gerrit and input into the filter field: libreoffice-X.Y.Z. If the results do not contain any entry for libreoffice-X.Y.Z.1, RC1 has not yet been tagged and string changes can still be committed.
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.
འགྲེམ་སྤེལ་མཇུག་གྲུབ།
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.