2.5 Release Planning

Announcements
1

All,

I know that many of you are waiting since a long time and have regularly asked for the date of the 2.5 release. Well, we have finally agreed on a schedule!

The 2.5.0 Release is planned for December 15, 2019.

To get there, we have today released another milestone (2.5.0.M5) and will do another one in two weeks time, i.e. 2.5.0.M6 on December 1. We will try to merge as many new bindings as possible by that date, so please help us on providing updates on review feedback in a timely manner. In exceptional cases, we will also still merge bindings until the 2.5 code freeze on December 8, which we will mark with a 2.5.0.RC1 build. The last week before the final release is then reserved for intensive testing by the community, so that there’s still a chance to fix critical issues before the release.

Looking forward to another big release in just a month from now!

Cheers,
Kai

89 Likes
2

Just FTR, we are running slightly late with the RC1 build - plan is now to do it by tomorrow night (Dec 9) with one day delay. The final release date won’t be impacted by this, though!

10 Likes
3

I am looking forward to switching to 2.5. How is it going with the anticipated release date? When can I do the upgrade?

4

Everything as planned - build is currently running. If everything succeeds, expect the announcement being made tonight in the forum.

14 Likes
5

Yeah!! Looking forward to it :heart_eyes:

6

So, how is it going? Any ETA ?

7

Hey, you have waited one year, you can wait a few more minutes without asking again for the status :stuck_out_tongue: .

6 Likes
8

Looks like finally the build was good: https://ci.openhab.org/job/openhab-release/70/

3 Likes
9

While that build was green, the build result still has some issues. So please refrain from upgrading.

1 Like
10

Ok, exactly at midnight the release was now successful. I’d thus consider it to be on time :slight_smile: . We anyhow didn’t mention any timezone :smiley: .

9 Likes
13

Please don’t use this thread for your issue, as it is just about release planning.
Better participate in an existing tread or open a new one.

2 Likes
14

Sorry in advance to spoil the party, but …
… wouldn’t a proper release procedure rather have been to

  1. provide a RCx
  2. wait for feedback on that from testers (a day, a week, whatever you consider appropriate)
  3. rename(!) RCx to Release (= rebuild, but on RCx codebase plus name change only)

If you release right after the build, you don’t know if the diff from RCx to release code has properly fixed all known issues or introduced new ones.
Which is what I somehow think we got to see this time.

There were also people to install the bad build from today’s afternoon because it is called 2.5.
True, their fault they didn’t wait for the announcement. But that also would not have happened with the procedure above.
You would also have some more time to build the release, plus you know the code compiles because it already did once.

So it would be a more reliable procedure (reliability in terms of keeping the deadline).
Maybe next time ? It’s also easier to meet deadlines that way :wink: , self-proclaimed or not.

15

Then why have RCx if feedback changes are not implemented?

Breakdown the release process into multiple parts?

  1. Build
  2. Test/Verify
  3. Release
  4. Verify repo (apt-get update was broken this time)
  5. Announce
16

I didn’t mean to say that. Of course, if there’s a need for changes due to feedback, these would be added. But this would result in RCx+1 and another iteration instead of Release.

1 Like
17

I think Kai and others were in a little bit of a hurry to get this one out. :wink:

18

Sure they were and they executed well on their plan.
Point is, though, that the plan has never been including that step from the beginning.

1 Like
19

rename(!) RCx to Release (= rebuild, but on RCx codebase plus name change only)

That would have helped nothing. The issue only occurred when publishing a release to our release repo (Bintray). The bug was there since months, so building more RCs wouldn’t have helped a bit. And no, we weren’t in a hurry, it was actually very quiet the days before the release - nothing critical showed up.

1 Like
20

With the bad build being announced as 2.5.0 early maybe ?
Ok it cannot help with everything but it would with those potential issues I named (which luckily didn’t show up) so still a good idea for next time ?

21

Im by no means a developer but I think Markus has a point. I work for a software company and we pretty much move the same way alpha>beta> rc(n)> if no blocking issue appears after feedback loop > ga else rc(n+1)

But first and foremost thanks al lot to everybody involved in the release of 2.5! I’m looking forward to the first 3.0 beta :sweat_smile: