Handling of existing PRs and 2.5.x updates

[kaikreuzer]

As a follow-up on https://github.com/orgs/openhab/teams/maintainers/discussions/2:

I commented here:

I am afraid that we won't get around providing a 2.5.1 for add-ons at some time. I would not expect to have an openHAB 3 release before end of 2020 and we already see many bug reports in bindings of 2.5, for which fixes are created right now. Providing a patch for the existing bindings should take some pressure from us wrt the 3.0 release. But yes, we can certainly say that we only pick selected major/critical issues to backport to the 2.5.x branch.
We nonetheless also have many bindings that are more or less done, but which didn't make it into the release (and the respective contributors are unhappy about that). So if we ship a 2.5.1 anyhow, we could also think about including those new bindings instead of only adding them to 3.0.

When switching from 1.x to 2.x development, we supported 1.x add-ons for 5 further years (up until now). We cannot say that we switch to 3.x now and completely leave 2.x behind. At least certain updates will have to be provided until 3.x is a full replacement and has a migration path.

We could also think of creating a new repo openhab3-addons and leave this one here in place as openhab2-addons - just as we have a openhab1-addons repo. Then it is up to the contributors to decide, where to contribute updates & fixes to. And it would allow every maintainer to decide, which repo he wants to help on the maintenance.

[kaikreuzer]

Maybe a suitable way forward to reduce the maintenance work to a single branch would indeed be a two step approach: Keep this repo as 2.5.x work only, so that none of the existing PRs break and existing users can benefit from the work.
Meanwhile we can get 3.x in a usable state and work on moving/migrating the add-ons to 3.x in the second phase (e.g. in Q3/20) and then only accept new PRs against that one - but that would mean that 3.x should be production ready by then.
Just out of interest: Who of you plans to move to a 3.x build for his production system by which date?

[wborn]

I think the two step approach makes a lot of sense. The same approach can be done for the zwave/zigbee repos. If we have a good enough migration script it can be applied on those repos and we might also get some working add-ons to test with OH3. :-)

We might want to reconsider if we really want 3.0.0 on the master branch for those repos. Contributors might be tempted to submit PRs to them.

I have multiple production systems and as soon as OH3 can run DSMR with MQTT I'd run it on my RPi3.

[Hilbrand]

For me it all comes down with what breaking changes do we expect that will break backward compatibility of OH3 with OH2 relate to addons? There were some between 2.4 and 2.5 but those were not world changing I believe. And I don't mean about the namespace change, because while completely breaks usage I believe it can be very easily scripted.

Because if we leave out any breaking changes we can simply develop for 3.0 on master and (semi-) auto git reset/renamespace back to a 2.5 branch or the other way around develop for 2.5.x an (semi-) auto git reset/renamespace to 3.0 branch until 3.0 is released.

[J-N-K]

I have one openhab1 addon left (fritzboxtr064) which prevents moving to OH3. I‘m currently developing a next generation binding for that and will probably move after that is at least in a usable state.

I think there are some JDK11 enhancements (for optionals e.g.) that are quite useful but not available on JDK8. As soon as we start using them, it‘ll not be possible to run these bundles on OH2, so this would be breaking.

Another thing is: we discussed moving some bundles from core to addons (e.g. transport bundles like MQTT). If we do that, this will be breaking, too. I would very much appreciate a decision here, because that needs some serious work.

[wborn]

With the two step approach we won't be doing any specific add-on changes until 2020Q3. So there will be no active OH3 branch on which we commit.

But we could have a OH3 add-ons build that uses the same OH2 branch, applies the migration script and uploads the compiled add-ons to the Maven repo. That way there is a single (OH2) branch and no way to commit OH3 specific changes.

When we have an active OH3 branch the contributors can use the same migration script to adapt their PRs from OH2 to OH3.

[cweitkamp]

Who of you plans to move to a 3.x build for his production system by which date?

Currently I do not plan to move my prod environment to 3.X. I am using one 1.X Action, and three 1.X bindings - fritzboxtr064 is one of them. But I have kind of backup environment which runs on snapshot version all the time and is responsible for some minor tasks in my home. I do not use any 1.x bundle over there.

[kaikreuzer]

With the two step approach we won't be doing any specific add-on changes until 2020Q3.

I'd definitely want to finish my work on the persistence service migration and those will end up in openhab-addons master.
For the two step approach, I'd thus rather suggest to start with an empty repo and add what is already 3.x specific. This would also leave the option for contributors to provide a 3.x version of their add-on, e.g. because they want to introduce breaking changes (which we should not allow for 2.5.x).
This would also allow us to move other bundles as @J-N-K mentioned (but btw, I do not recall a discussion on such a move for MQTT, but that's offtopic...).

We might want to reconsider if we really want 3.0.0 on the master branch for those repos. Contributors might be tempted to submit PRs to them.

Imho master should stay 3.0.0 as this way we can keep all normal snapshot/milestone/release build setup as is.
To avoid PRs being created against it by accident, we should definitely set 2.5.x to be the default branch, which is easily possible in Github.

[Hilbrand]

I think and hope everybody agrees that we want to avoid a situation were people will create some pr's against 3.0 and some against 2.5.x So either we should merge everything on 3.0 or on 2.5.x and provide a synchronization between those branches related to the namespace change.

I would not prefer to start a new repo for 3.0. If we want a new repo make it one for 2.5.x for bindings that are not compatible with 3.0.x. We keep the 2.5 branch auto reverse-migrated on the current repo with addons reverse-migrated not being compatible with 3.0 being removed and those addons should be on the 2.5.x repo.

And also try to avoid breaking changes in the addons api that would impact all addons. So that doesn't includeapi changes because of completely new functionality for a specific group of api's, like the persistence api would be. Those could be excluded from the reversed-migration to 2.5 and if any current persistence changes would be required they can be made in the separate 2.5.x repo.

[kaikreuzer]

I think and hope everybody agrees that we want to avoid a situation were people will create some pr's against 3.0 and some against 2.5.x

No, sorry, I do not agree. If it weren't possible to merge PRs against two different branches, there is no need for those branches at all.
I should definitely be possible to put 3.x specific stuff in master (like persistence services, io bundles, new bindings that want/need Java11 only support and maybe rely on new sitemap features, major refactorings of bindings that completely break backward compatibility etc.) while maintaining existing add-ons in the 2.5.x branch (as the default as this is where most activity is).

provide a synchronization between those branches related to the namespace change.

I would actually claim that we do not need (nor should have) this at all on source code level. Imho, the master branch can start with what is 3.x specific and not have any bindings for the start. If we have a script that can convert 2.5.x code, we could directly apply it in the build and provide "preliminary" 3.x compatible add-ons through this approach.
This way, we could clearly avoid getting in a mess with PRs for the same add-on being created on master and 2.5.x - and I guess this is your main concern, @Hilbrand, right?

[kaikreuzer]

As an example, #6678 seems to be a candidate which has to go to the master branch and which won't be needed on 2.5.x (and isn't compatible with it).

[kaikreuzer]

Ok, now that openhab/openhab-core#1294 is merged, I guess we should remove the existing add-ons from master and make the 2.5.x branch the default one for PRs.
We can still discuss what and how to add back on master - but I stick to my suggestion to only maintain 3.x-specific code in there, while creating 3.x-compatible bindings from the 2.5.x within the build. Let me know if you think this is a stupid idea and you see a better way to progress.

[wborn]

It's probably the best of both worlds where we can still make some progress regarding 3.0 while preventing a lot of porting PRs.

It would also be helpful if we inform our contributors about what PRs go to which branch using a sticky issue/forum post/README.md. The Eclipse IDE config may also need an update when most PRs should go to the 2.5.x branch. Maybe we can also use a bot to label PRs that don't go to the default branch?

[kaikreuzer]

It would also be helpful if we inform our contributors about what PRs go to which branch using a sticky issue/forum post/README.md.

Absolutely! As mentioned in https://community.openhab.org/t/openhab-2-5-has-been-released/87716/45, I planned to do so - but I first wanted to come to an agreement on what we should communicate.

The Eclipse IDE config may also need an update when most PRs should go to the 2.5.x branch.

Good idea, we might want to change the checked out branch for the moment.

Maybe we can also use a bot to label PRs that don't go to the default branch?

What exactly do you have in mind here?

[wborn]

What exactly do you have in mind here?

AFAIK the GitHub PR list doesn't show the base branch of PRs (unlike GitLab). So maybe we can improve that by using something like pr-branch-labeler to automatically add a "oh3" label to PRs that go to the master? There may be better labelers but I haven't looked into them all.

Ideally I'd also like to have a bot to add a comment when someone tries to merge all add-ons into the master. That might happen a lot. But I haven't found one so I guess I'll just create a saved reply for that. 😐

[kaikreuzer]

Ok, such "oh3" labels could make sense. If anybody wants to look into it, feel free :-)

I am not so concerned about seeing too many accidential PRs against master - I have now set the default branch to 2.5.x, so PRs are automatically created against this one and I doubt that many people will manually change that.

[kaikreuzer]

It would also be helpful if we inform our contributors about what PRs go to which branch using a sticky issue

I have created the pinned issue #6702 - if you think this is ok, I will also post it on the forum, once we are back with a 3.0.0 snapshot build.

[wborn]

It looks OK to me and I also see you synched the missing commits to 2.5.x! 👍 We might also want to go through existing PRs and update the base branch to 2.5.x.

[kaikreuzer]

Yes, might be better than explaining how to do this to every single contributor...

[wborn]

Changing the base results in a lot of commits :-/
See: #6699

[kaikreuzer]

That's why I mentioned that an additional rebase is necessary as well.

[cweitkamp]

FTR: I just updated the branch protection rules for 2.5.x to prevent users from merging (#6850).