Process for refactorings for 3.x and patch releases for 2.5 #1506
Replies: 63 comments
-
|
That's a difficult question. I think scripting the namespace-change should be possible. But we talked about JDK11 and also about moving some bundles (like mqtt) from core to addons. Both will break compatibility, i.e. a MQTT3 binding-bundle will differ from MQTT2.5.x binding bundle not only by different namespaces (not sure about other bindings/core-bundles). Going with option 2 is not ideal, too. We can't test 3.0 without bindings and that will probably leave bugs unnoticed before we move addons. |
Beta Was this translation helpful? Give feedback.
-
|
The "classic" way would be to just keep going and do manual backport of certain commits to the 2.5.x branch - or a manual forward-port of existing PRs that we merge against 2.5.x. This would probably be most flexible, but also most effort. And suitable "namespace switch" scripts would be very handy for such an exercise. |
Beta Was this translation helpful? Give feedback.
-
|
Do we know or has someone an overview of all what needs to renamed? What the impact is? Like for jsondb? rules? etc? I haven't seen an issue 😉 How about namespace of compatibility mode? Does that come into conflict when we rename to openhab? If we know that we identify how much effort it will be. Only renaming can be very likely completely scripted (like I did for for the bnd migration, were I had a script to migrate completely automatically and also a script to completely fix it when there was a merge conflict on a migration pr). I personally would prefer to migrate as soon as possible. Otherwise we keep maintaining different realities. I expect the rename to be relatively simple. I would even suggest to just release this as 3.0 so we can move on. I realize this would be a bit strange as Kai has up-ed the expectations for 3.0 in the blogpost by promising a new UI (which I'm not sure how this will unfold given the current development of the ui (see my comment on the ui repo) So an early release of 3 would bring nothing new for the user while suggesting a big change because of the new number. Another option could be to release it as 2.99 or something? Another option could be to do the rename just before a final 3.0 release when all other changes are made. If it's a scripted process that can be done in short time this would be an option. However it also mean we need some kind of roadmap with what would actually be in 3.0 other than the rename. And except for wishes I don't know of any large new features that can be guaranteed given it's all voluntarism... With regards to the open pull request. I suspect there will keep being pull request so that will always be an issue I think. However we could merge or handle the enhancement/bug fixes as those are probably the least convenient to change after a rename. New bindings might be easily script migrated were either we could offer help with a script or provide the script. Also we've been tagging a number of older pr's in recent months with stale, so I suspect we can clean up on those before and see for the other new binding pr's if we can merge as much as possible first. |
Beta Was this translation helpful? Give feedback.
-
Well, as I said: Everything that currently uses
This will indeed collide and another good reason to remove it at the very same time.
As mentioned: We will have to maintain both branches for a while, no way around that. So the question is only, what process is better: To maintain a single one and bulk port stuff or to decide on every single PR, where to merge it and whether to back/forward port it.
Is anyone scripting-fluent enough to come up with a script for the namespace change? Which could also be applied on a single binding, e.g. after having merged it in the 2.5.x branch and needing to forward port it to master? Maybe @wborn? 🤞 |
Beta Was this translation helpful? Give feedback.
-
|
To come with a more concrete question/decision:
|
Beta Was this translation helpful? Give feedback.
-
|
In terms of packaging I think it would make sense to stop linuxpkg builds until the 2.5.x branch is setup in the way above. A new package needs to be setup for openHAB 3.x so that needs to be thought of carefully too. Should I discuss options for this in a new @openhab/maintainers post? |
Beta Was this translation helpful? Give feedback.
-
|
I have deactivated the linuxpkg build for the time being. |
Beta Was this translation helpful? Give feedback.
-
|
If we want to keep both versions for now we could also do the following with the openhab2-addons:
This would make it easy to maintain, but will break when we would make breaking changes in core that would require bindings to be updated (something that would be a problem also in any scenario). One could argue that with the master isn't 3.0 and 2.5.x is still leading. This would also mean new bindings would still always be developed against 2.5 and no pr's should be made against the 3.0.x branch as it's reset everytime. Here is a script for core: https://gist.github.com/Hilbrand/94c3a1049a494d763223e2d33f4e8e73 Regarding removing compat layer. That is a big change and will probably not completely be a surprise, but still be somewhat unexpected. if we do that we should startup a migration program (Looks like I need to finish my tutorials 😄 ) Another option could be to move compat to a package including While we're at it. Can we also replace Nashorn with Graal for the rule engine? |
Beta Was this translation helpful? Give feedback.
-
|
Throwing my few cents worth into the pot :)
I don’t mind too much what approach we take to maintain the 2.5 branch so I’ll not comment on that. And I think we’re probably getting off topic here when we talk about the compatability layer - however, I’ll take it a little more off topic (sorry)…
I think if we’re on OH3, then maintaining compatibility with OH1 is getting a bit long, and we should consider having some larger discussions about resolving broader issues with the architecture. I’m not sure if there is another discussion forum about the OH3 direction, but IMHO we should look to have a broader discussion before jumping in and building something. I’m sure people would love to maintain OH1 compatibility, but we should take care in that by trying to maintain such compatibility we will limit what can be done in OH3.
If there a place where we should discuss this direction, or has this already been done?
… On 17 Dec 2019, at 22:03, Hilbrand Bouwkamp ***@***.***> wrote:
If we want to keep both versions for now we could also do the following with the openhab2-addons:
Create a new branch 3.0.x
Fix the master branch to use 2.5.0 openhab-core
Script the migration of smarthome to openhab on the 3.0.x branch and git reset that branch to the master and rerun the script (for example each night like a snapshot build)
When we make the actual switch to 3.0 and not maintain 2.5, the 3.0.x branch can become a pr to the master and with that the migration will be completed.
This would make it easy to maintain, but will break when we would make breaking changes in core that would require bindings to be updated (something that would be a problem also in any scenario). One could argue that with the master isn't 3.0 and 2.5.x is still leading. This would also mean new bindings would still always be developed against 2.5 and no pr's should be made against the 3.0.x branch as it's reset everytime.
Here is a script for core: https://gist.github.com/Hilbrand/94c3a1049a494d763223e2d33f4e8e73 <https://gist.github.com/Hilbrand/94c3a1049a494d763223e2d33f4e8e73>
Maven build will break on the compatx and itest for persistence. I haven't tested if it actual runs. (and it will not be compatible with any existing jsondb configuration obviously)
Regarding removing compat layer. That is a big change and will probably not completely be a surprise, but still be somewhat unexpected. if we do that we should startup a migration program (Looks like I need to finish my tutorials 😄 ) Another option could be to move compat to a package including legacy.
While we're at it. Can we also replace Nashorn with Graal for the rule engine?
—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub <https://github.com/orgs/openhab/teams/maintainers/discussions/2/comments/8?email_source=notifications&email_token=AAH6IQ5HSCACGDVHZ2PGO2TQZFECHA5CNFSM4J3SV7IKYY3PNVWWK3TUL52HS4DFWNCGS43DOVZXG2LPNZIG643UKJSXA3DZVJRW63LNMVXHIX3JMTHAAAUCXE>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAH6IQ7LCMNOVOQ4T6WJ3J3QZFECHANCNFSM4J3SV7IA>.
|
Beta Was this translation helpful? Give feedback.
-
|
@cdjackson, thanks for the excellent observations about getting a discussion going regarding whether OH3 is a breaking change from OH1. This seems to be a governance question of high importance. Do I remember correctly that a council was created for this purpose? Perhaps I am thinking of an architecture council. In this case, I would strongly argue for inclusion of users in the discussion, specifically users who are not developers. (Yes, I am volunteering if you want me...). So to your question, where should this be discussed? As for maintaining backward compatibility with OH1, my feeling is that OH1 adopters are significantly different from OH2 adopters. Specifically, it took some pretty hard work to get OH1 working, so I suspect most of those people were/are technical, compared to OH2 users, who may still be pretty technical, but not as hardcore as OH1 folks. If I am right, then breaking compatibility may result in inconvenience, but the deployed base is (probably?) relatively small, and theoretically, those who have it have the technical chops to deal with the change. But, and this is a very big but, if this were my business, I would definitely want to verify this hypothesis by some means, perhaps surveys? other ideas? but anyway, it seems worth the effort to not make a mistake. Also breaking changes and the perceptions they create can be difficult (impossible?) to correct after the fact. So I would strongly suggest that there needs to be a lot of thought about messaging, tutorials, documentation and support for getting from OH1 to OH2/3, etc. It is worth getting this right. My two cents... |
Beta Was this translation helpful? Give feedback.
-
|
Oh yeah - one other thing. What are the end-user driven use cases or requirements behind needing to make a breaking change? It is worth putting those down somewhere. If for no other reason, it helps us explain why we "broke OH1" (yes - some people might say that). Perhaps it is clear to all now, but trust me, two years from now, if something comes up to bite us, we will appreciate knowing why we did this. |
Beta Was this translation helpful? Give feedback.
-
|
Guys, this thread is NOT about directions for openHAB3. Our master now IS openHAB 3 development and we should move towards getting snapshot builds working for it asap.
This is what my suggestion wants to address. Whether or not to restore 1.x compatibility and how can be decided separately (and yes, there has been plenty of discussions already and the final decision will be taken by the AC). |
Beta Was this translation helpful? Give feedback.
-
|
@Hilbrand Thanks for the script, that looks like a good starting point! |
Beta Was this translation helpful? Give feedback.
-
|
Hi Kai, However, I'd still like to have a discussion about what OH3 is trying to achieve - I'm not aware of any previous discussions (other than a few ad-hoc points) and I think before starting out on a development, we really should understand WHAT we are trying to develop. Or are you basically just saying that OH3 is OH2 with a change of the ESH namespace? Or is this not up for discussion? So, you point out -:
But my earlier question still remains -:
Chris |
Beta Was this translation helpful? Give feedback.
-
As a very first step to get snapshot builds working again: Yes, that's about it!
There was already a lot of discussion, see https://community.openhab.org/t/directions-for-openhab-3/67372 for the general direction and https://community.openhab.org/t/removal-of-the-oh-1-x-compatibility-layer/67553 on the future of the compat layer. |
Beta Was this translation helpful? Give feedback.
-
Sounds absolutely fine to me as next steps! |
Beta Was this translation helpful? Give feedback.
-
|
Heads-up: If there's no veto, I will do the 2.5.1 build tomorrow morning. |
Beta Was this translation helpful? Give feedback.
-
|
@J-N-K and others: Please refrain from merging PRs until the build is successfully done - https://ci.openhab.org/job/openhab-release/72/ |
Beta Was this translation helpful? Give feedback.
-
|
Sorry. Didn‘t see that. Will stop now. |
Beta Was this translation helpful? Give feedback.
-
|
It seems it seems me and Jenkins messed up the master branch. How do we fix that? |
Beta Was this translation helpful? Give feedback.
-
|
You mean the 2.5.x branch with openhab/openhab-addons@e2b7633, right? I will remove this commit and do a force push. @pfink, looks as if we need to do slight changes to the jenkinsfile... |
Beta Was this translation helpful? Give feedback.
-
|
Ah, no - looking closer at it, Jenkins did everything correctly - it made sure that the PRs that you had merged after the release build had already started are correctly put on top of the version change to 2.5.2. |
Beta Was this translation helpful? Give feedback.
-
|
The single commits are lost due to the merge commit. This is correct from the code-POV but will probably be a problem for generating release-notes. |
Beta Was this translation helpful? Give feedback.
-
|
No, the release notes are generated from the PR list, so all should be fine. |
Beta Was this translation helpful? Give feedback.
-
|
All, feel free to merge PRs again - the release build is done and the artifacts are published (incl. the linux packages). I'll compile the release notes tonight and do a small announcement in the forum. |
Beta Was this translation helpful? Give feedback.
-
|
Did anyone try 2.5.1 yet? I tried installing a new instance with the Demo package but it fails:
|
Beta Was this translation helpful? Give feedback.
-
|
Just fixing it, see https://community.openhab.org/t/openhab-2-5-x-patch-releases/90248/5. |
Beta Was this translation helpful? Give feedback.
-
|
Switching to 2.5.2-SNAPSHOT makes the itests fail, see https://ci.openhab.org/view/Integration%20Builds%20(2.5.x)/job/openHAB2.5.x-Addons/21/console. |
Beta Was this translation helpful? Give feedback.
-
|
Fixed itests: openhab/openhab-addons#6828 |
Beta Was this translation helpful? Give feedback.
-
I hope we can integrate those steps into the release script. Therefore I created https://github.com/orgs/openhab/projects/3#card-30705443 and asked openhab/openhab-core#1277 (comment). |
Beta Was this translation helpful? Give feedback.
-
Hi @openhab/maintainers,
Now that the 2.5 release is done and our master branches have become 3.0.0-SNAPSHOT, we will need to discuss how to best proceed.
One technical (and legal) necessity is to refactor our openhab-core code from
org.eclipse.smarthometoorg.openhab.corenamespace. Doing so will mean that all add-ons will need to be adapted at the same time and will thus immediately become incompatible with a 2.5 runtime - including the 130+ open PRs that still exist on openhab2-addons.As I have mentioned in the release blog post, I don't think we should do a 2.6 release, but I do believe that we will have to ship 2.5.x versions of the add-ons, since it will take too long until a 3.0 release becomes available. We could create a 2.5.x branch in openhab2-addons (and maybe a 1.14.x one in openhab1-addons) and merge any PR that is not breaking any backward compatibility against this branch. From there, we could still build addons.kar and publish online-repos with those versions. It would imho also be ok to merge new bindings there (for which we still have plenty of PRs).
If we go this route, the question is: When and how do we refactor the add-ons to the new namespace on the master branch? Can we come up with a clever script that does this automatically for us and we can do bulk syncs from 2.5.x to master from time to time? Or shall we first completely remove the bindings from master, work on the 3.0.0 build (with new namespace, new UI, etc.) without any bindings and then do the migration as a single operation (and from then on require PRs against master and potentially separate backports against 2.5.x)?
What's your opinion on the best process here?
Beta Was this translation helpful? Give feedback.
All reactions