openHAB Milestone builds

Yes of course - 2.4.0-1 is the latest available on the ‘release’ channel/repo.

There have been some issues and changes with the repos and keys (required to trust a repo) to no longer be valid. Eventually there was an error updating lists from the repo so latest (M3) was missed and M2 taken. But that’s just a guess. Either way there was no relevant change of behavior in openHABian.

It looks like this is the order of what happened here:

  1. You used openhabian-config
  2. openHABian updated the list of apt packages from the currently known repositories.
  3. At this point, apt is looking in bintray for the milestone packages, which moved to artifactory before the M3 build was released.
  4. openHABian updated itself, the list of repo changes here to correctly use artifactory.
  5. You used the menu option to update (which should update openHAB’s packages).
  6. openHABian issued an update command, but did not tell apt to look at the new list of sources, so it updated from bintray, the latest version it held was M2.

This is a bug that happens in a very specific scenario, and it looks like you found it! :wink:

Updating a second time should move to M3?

Yes :slight_smile:

Typical! It always happens to me :slight_smile:

I guess I might as well upgrade to M3 then… No reason to use M2 when there are fixes in M3. It wasn´t my attention to upgrade today, but hey… Now I might as well search for bugs in M3 :smiley:

1 Like

Sorry, I may have been wrong there. I had forgoten that there is a specific option to change to the new milestone build you’ll need to use the other updating option as mentioned here:

A suggestion…
Would it be too much to ask, that openhabian-config can be changed to use the correct names of the different versions… (ie, Release/Stable, Snapshot, Milestone).
I really find it confusing to select a “testing option” for a Milestone, when I know there is a Snapshot as well, which in my opinion is a “testing version” as well. Infact everything beside Release/Stable is “testing” in my opinion.

The official version repositories are Stable, Testing, and Unstable.
The Unstable repo contains snapshot versions to form the next testing version.
The Testing repo contains Milestone versions for wider testing to form the next stable version/

If you have issues with this little bit of complexity, perhaps OpenHAB configuration is too complex for you. :wink:

1 Like

Its not that I have a huge issue with it. But give me one good reason not to use the same “names” (Indications)? It´s not that the computer ran out of letters, I Hope :wink:

Honestly, this is a suggestion simply to avoid any confusions… If it was diffcult to change, I could be able to understand. But it doesnt seem like that… Its just a suggestion to change some text.

Confusing the “old-timers” that have used & developed OH for years? :thinking::smiley:
As people get older, their memories deteriorate. :joy:

See my link. It was changed from milestone to testing because if there is a release there the lastest testing is the release and there is no milestone. But I don’t think it got any clearer by naming it testing. You can open a pr just for the text. It maybe should say something reflecting it’s a milestone, but not when the lastest is the release.

2 Likes

Is this thread getting close to being “off topic”?
I am well aware that the complexafacation of OH is way over my head, but I keep plodding along reading the forum’s and Docs that are very well documented. Everyone is so helpful and I am just grateful to be a part of it coz … We are OH Strong :muscle:

Thanks again EVERYONE!
Steve-

2 Likes

You must be new here. :rofl::rofl:

Actually @Bruce_Osborne I have learned a lot from your posts in many of the threads on this forum. With no formal training in programming I only wish I had your knowledge. Many thanks to you for all of your help you have given me and many others who get stuck in this learning curve. On another note my upgrade to OH-M3 went great :). or was it testing? Hhhmmm… LOL

Thanks Again
Steve-

Thank you.
I looked after I posted and you have been here much longer than I have. Actually I have gotten sidetracked from my OH system and am cleaning up our Z-Wave device database. Quite the challenge looking for sparse documentation from companies no longer in existence.

Hi OH’ers,

I just did an update from 2.4.0 Stable straight to 2.5.0 M3 on a Mac running OS-X. Just wondered if there’s a quick fix to my now broken openHAB environment. I now get the following in line one of my logs:

07:24:37.279 [ERROR] [org.openhab.binding.zwave            ] - FrameworkEvent ERROR - org.openhab.binding.zwave
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.zwave [203]
  Unresolved requirement: Import-Package: gnu.io

I did have a bit of look around and found some references to similar unresolved requirements, but nothing specific to zwave. Please let me know if I should post this elsewhere, or more logs are needed - however this was a direct result of upgrading to M3. thanks for any ideas…

Dave.

This is not related to M3, but clearing the cache. You have zwave manually installed, so you need to manually resolve it’s dependencies when the cache is cleared. So, reinstall the openhab-transport-serial feature. Or uninstall the manual install of zwave (delete it from /addons/) and install it through Paper UI or the console.

2 Likes

I have not done that upgrade jump.
Some people find that either stopping & restarting OH can help or stopping. cleaning out cache & temp files, & restarting OH (longer startup the first time)

@Bruce_Osborne and @5iver, thanks gents. Clearing the cache and tmp directories, bundle:uninstall of the previous zwave driver and reinstalling zwave version 2.5.0.M3 worked - thanks very much for the prompt hint.

2 Likes