Implement versioning, releases and release notes

[5iver]

I'd like to do a simple version check on OH startup, to compare the core package version with what is in GH and log a message. This could be done for community packages too. So far, we haven't utilized GH releases, and hopefully there is a way to tie in a script after each merge to update the core package version number and release notes, so that it is automated.

• Compare core to GH, and log/notiy if there is an update available. This could go into core.init.py, but that would slow things down, or the startup delay script. An Item and cron rule would probably be cleanest.
• Community modules and scripts can optionally set a minimum core version, which gets compared to core, and then messages (maybe exit?) if the core version is not new enough. This can go into the scriptLoaded function.
• Compare core to OH version. Core will need a minimum OH version to be set.

[mjcumming]

Scott,

Openhabian would be a great way to do this - and to install Jython.

I am not sure I want scripts autoupdating them selves... prefer to do an update manually.

[5iver]

I am not sure I want scripts autoupdating them selves... prefer to do an update manually.

I agree... I was thinking more along the lines of a log message that there is updated code. Community scripts may require a certain version of the core package, and kick out errors if an older version is being used (I'm currently running into this with the OWM script and changes to core.items and a new core.links). The ability to refer to a version will also help when issues are reported.

My reference to an automated script was not in regards to deployment, but for updating the release notes (I'll try to make it clearer in the OP).

[diijkstra]

Great idea to have any version identifier! I think for starter we should add __version__ attribute to core module plus log on initialization (or maybe fancy item? ;-) ). Did you though about versioning scheme (ex. semantic versioning )? I think I can hack something today ;-)

I would also love to have proper distribution (think setuptools and pip friendly).

[fastlorenzo]

Maybe you should create a repo per community module? Might be easier to maintain/install

Lorenzo Bernardi

On 29 Jan 2019, at 17:55, diijkstra notifications@github.com wrote:

Great idea to have any version identifier! I think for starter we should add version attribute to core module plus log on initialization (or maybe fancy item? ;-) ). Did you though about versioning scheme (ex. semantic versioning )?

I would also love to have proper distribution (think setuptools and pip friendly).

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[5iver]

I have some changes to commit for Jython 2.7.1 compatibility, and I'll include updating all of the files with a version. I'm thinking the original_(<-2.3) branch could go in as 0.1.0, and I'll just start incrementing with 1.0.0. I'll also play with releases in GH, by putting one out for the old stuff. Community stuff should to use it's own individual versioning.

I'm thinking we will need two flavors of version checking...

• Compare core to GH, and log/notiy if there is an update available. This could go into core.init.py, but that would slow things down, or the startup delay script. An Item and cron rule would probably be cleanest.
• Community modules and scripts can optionally set a minimum version, which gets compared to core, and then messages (maybe exit?) if the core version is not new enough. This can go into the scriptLoaded function.

If someone wants to get these together, that would be great!

I would also love to have proper distribution (think setuptools and pip friendly).

Distribution will come in the form of a bundle that users can select in Paper UI!

Maybe you should create a repo per community module? Might be easier to maintain/install

I don't think so. For distribution and organization, one repo seems best. This repo is a starting point, and the whole repo could potentially move under OH... maybe even bundles made available for each community submission. The NGRE and collaboration on automation will be big in OH 3. I've got Jython scripted actions working in Paper UI, and can distribute templates. Once the ESH migration is done, I'll submit a PR for it, and package the OWM script as a template that you can import through Paper UI, directly from GH!

[fastlorenzo]

Community stuff should to use it's own individual versioning.

Sounds like a good plan, but how will you manage GitHub tags for community stuff if they are in the main repo ?

The NGRE and collaboration on automation will be big in OH 3. I've got Jython scripted actions working in Paper UI, and can distribute templates. Once the ESH migration is done, I'll submit a PR for it, and package the OWM script as a template that you can import through Paper UI, directly from GH!

Awesome! That would be great to help users installing the modules

Compare core to GH, and log/notiy if there is an update available. This could go into core.init.py, but that would slow things down, or the startup delay script. An Item and cron rule would probably be cleanest.

I agree with the Item/cron approach as otherwise the check would only be done at startup

[diijkstra]

Sounds like a good plan, but how will you manage GitHub tags for community stuff if they are in the main repo?

I think whole repo (OH-JS) can be tagged and released as one release, but each Community 'plugin' can have its own version. One could see a release of new plugins once the release of all repo is done.

I'm thinking we will need two flavors of version checking...

I would definitively add third one, a check against of OpenHAB version against supported by core. Simple, one time only, on startup. Good thing for not backward compatible changes in ESH/OpenHAB.

Community modules and scripts can optionally set a minimum version, which gets compared to core, and then messages (maybe exit?) if the core version is not new enough. This can go into the scriptLoaded function.

You mean external stuff from this repository? If so, than yes - I would really used in my private stuff. If you mean modules and scripts inside this repository, I think it should be enforced that they are compatible or dropped.

[5iver]

Sounds like a good plan, but how will you manage GitHub tags for community stuff if they are in the main repo ?

I'm kind of hoping we have more of an official solution before we need it here. We can think about more repos when there are some more submissions! :smile:

Awesome! That would be great to help users installing the modules

Not modules... just scripts. A lot of the modules will get absorbed into a scripting API, and there'll be an installer bundle.

I think whole repo (OH-JS)

And Groovy... hopefully Kotlin!

I would definitively add third one, a check against of OpenHAB version against supported by core.

Yes! A core minimum supported OH version.

Max could be done too, but we'd have to maintain a table that would need to be downloaded each time. Seems like too much.

If you mean modules and scripts inside this repository, I think it should be enforced that they are compatible or dropped.

An example of what I was thinking... the OWM script needs the changes in core.items and the new core.links. So, the check would warn that the core did not meet the min version requirement.

Changes to core could/will break scripts, just like openhab-core breaks bindings, so there will be some maintenance. But I agree, if they aren't updated in time for a release, then they should be somehow separated, like into a 'Not Compatible' directory.

[TareqK]

For release notes and docs, has anybody looked into making living documents from code/ adding documented unit tests for examples?