Train Stops

And the sons of pullman porters and the sons of engineers Ride their father’s magic carpets made of steel Mothers with their babes asleep are rockin’ to the gentle beat And the rhythm of the rails is all they feel

So, LibreOffice does its releases on a train release schedule and since we recently modified the schedule a bit (by putting out the alpha1 release earlier), I took the opportunity to take a closer look and explain a bit on what we are doing. With this every 6 months of LibreOffice development currently roughly look like this:

week after x.y.0

development

release candidates

finalized releases

fresh

stable

fresh

stable

0

x.y.0

1

x.y.1~rc1

x.(y-1).4~rc1

2

3

x.y.1~rc2

x.(y-1).4~rc2

4

x.y.1

x.(y-1).4

5

6

x.y.2~rc1

7

8

x.y.2~rc2

x.(y-1).5~rc1

9

x.y.2

10

x.(y-1).5~rc2

11

x.y.3~rc1

x.(y-1).5

12

13

x.(y+1)~alpha1

x.y.3~rc2

14

x.y.3

15

16

17

18

x.(y+1)~beta1

19

20

x.(y+1)~beta2

x.(y-1).6~rc1

21

22

x.(y+1)~rc1

x.(y-1).6~rc2

23

x.(y-1).6

24

x.(y+1)~rc2

25

x.(y+1)~rc3

The last two columns are most visible to most visitors of the LibreOffice website. Those are the versions found on the LibreOffice Fresh and LibreOffice Stable download pages. We are in roughly at week 18 after 4.2.0 release now, and the versions available are 4.2.4 fresh and 4.1.6 stable. A careful reader will note that according to that schedule we should be at 4.2.3 and 4.1.5 — that is true, but the 4.2 series still had an extra 4.2.1 intermediate release to adjust the schedule of 4.2 in direction of the current plan. This is not expected for future releases (also note that there is always some flexibility in the plan to allow for holidays etc.)

If you count all the prereleases, release candidates and releases, you will find that we do 25 of those in 26 weeks. Beside the fact that this is a lot of work for release engineers, one might wonder if anyone can keep up with that, and if so — how? The answer to that depends on how you are using LibreOffice.

self deployment on LibreOffice fresh

If you are an user or a small business installing LibreOffice yourself, you will probably run LibreOffice fresh and the table above simplifies for you as follows:

week after x.y.0

development

release candidates

finalized releases

0

x.y.0

1

x.y.1~rc1

4

x.y.1

6

x.y.2~rc1

9

x.y.2

11

x.y.3~rc1

14

x.y.3

18

x.(y+1)~beta1

20

x.(y+1)~beta2

22

x.(y+1)~rc1

24

x.(y+1)~rc2

25

x.(y+1)~rc3

The last column shows the releases you are running. If you are a member of the LibreOffice community it would be very helpful if you also spend some time of this 6 months period for three actions:

running at least one of the release candidates in the table (available for download here) before the final is released.

running at least one beta releases in the table. Note that there will be a bug hunting session on the 4.3.0 beta release this week, that will help you get started.

running a nightly build once anywhere in the weeks 1-18. Note that if you are getting excited about seeing the latest and greatest builds while they are still steaming, there are tools that can help you with this on Linux and Windows.

If you do these each of these three things once in the timeframe of six months and report any issues you find, you are helping LibreOffice already a lot — and you are making sure that the finalized releases of the fresh series are not only containing all the latest features, but also free of severe regressions.

bigger deployments on LibreOffice stable

If you are not installing LibreOffice yourself, but instead have a major deployment administrated centrally, things are a bit different. You might be more conservative and interested in the releases from LibreOffice stable. And you probably have professional support from a certified developer or a company employing certified developers.

week after x.y.0

development

release candidates

finalized releases

1

x.(y-1).4~rc1

4

x.(y-1).4

8

x.(y-1).5~rc1

11

x.(y-1).5

13

x.(y+1)~alpha1

18

x.(y+1)~beta1

20

x.(y-1).6~rc1

23

x.(y-1).6

If you intend to deploy one series of LibreOffice (e.g. 4.3), there are two things that are highly recommended to be done:

make the alpha or beta releases available quickly to interested volunteers in your deployment early. They might find bugs or regressions that are specific to your use of the software.

make the release candidates of versions that you intent to deploy available early to your users.

Of these two actions, the first is by far the most important: It identifies issues early on in the life cycle and gives both your support provider and the LibreOffice developer community at large time to resolve the issue. In fact, I would argue that if you have a major deployment, the only excuse for not making available prereleases, is that you made available nightly builds.

Ubuntu

So, Ubuntu qualifies as a “bigger deployment” and I have to take care of LibreOffice on it. Also people want to be able to run the latest and greatest LibreOffice releases from the LibreOffice fresh series. Do I follow my recommendations here? Yes, mostly I do:

prereleases are made available as bibisect repositories rather quick (build on Ubuntu 12.04 LTS). In addition, fully packaged versions of LibreOffice are build in the prereleases PPA as early as starting with beta1.

So, you are invited to run or test builds from these PPAs — or download the bibisect repositories — to keep LibreOffice releases coming in the steady and stable fashion they do. Finally, there is a bug hunting session for LibreOffice this week and as said above, no matter if you are running a huge deployment or installing on your own, you are helping LibreOffice — and yourself, as a user of LibreOffice — a lot by testing the prereleases:

Like this:

Related

About bmichaelsen

2 responses to “Train Stops”

I think that because of branching LO’s versioning scheme is too complicated. Maybe it is better idea for future LO devs and QA team to have one real stable branch for users, one constant beta for testers and one constant master for devs. It seems to work great for browsers like Chrome or Firefox. Users are getting new version every x weeks and are pretty much version unaware. Ask anyone which version of the browser she/he is using and probably most people do not know :).

As for the complexity: The average user gets guided by the update notification or the releases of the Linux distribution. All of the above explains what happens behind the curtain. Well, and why its so important to test the beta prereleases. If you dont care about the why — feel free to just trust me when I say “test the prereleases, no matter how you use LibreOffice”. ;)

P.S.: Finally, note that a branch only gets more stable when lots of people are running it for some time and report the issues they see. The name of a branch never changes anything about that. However, most users are very much eager to get the new features and happy to be able to run those newer versions promptly.