Is there a branching strategy for this repository

[Confectrician]

No template, since this is more a general question.

I am collecting contents for improving my xtend 2 js migration tutorial in the community.
Can be found here: https://community.openhab.org/t/migrating-dsl-rules-to-jsr223-javascript-with-a-case-example/73352?u=confectrician
I would like to clone and "maintain" the helper libraries through this repository, like it was suggested in the corresponding thread.

But while collecting i have asked myself if it is safe to use the master branch for this, since this repository is continously changing.
At first this is great, since it means we have a nice amount of activity.
On the other hand it could mean that the repo may get some unstable commit which would then could be pulled by users without knowing about the unstable state.

So maybe it would be nice to have a release branch for tested and stable features.
Due to my busy schedule last weeks i have not followed all issues and pull requests here and i hope that this has not been discussed already and i missed it.

What are your ideas about it?

[jpg0]

To add to this: I have a load of newer JS code that I'd like to contribute, but the current version of OH can only support up to ES5. I'm skeptical that it will be worthwhile/possible to maintain full backwards compatibility. It would be great if there were branches devoted to stability versus bleeding edge.

[Confectrician]

I have one addition too:

It would also be nice to have release branches that just include the "code" contents.
Currently i have to download everything. Then copy just the contents of "Core/automation" folder.
So a possible release branch, should just include the folders jsr223 and lib.

This way it could get easily pulled from the openHAB instance via git.

[jpg0]

I guess this depends on whether we encourage git as the installation tool. I know from @openhab-5iver that bundling this code into the automation framework bundle(s) is a possibility. Also regarding the JS libs, the code that I've written is now on npmjs, so can be installed/updated by simply running npm i ohj, which I'd recommend using over git (I don't know enough about python packaging as to whether it's feasible there too.)

[rkoshak]

Given that Scott has figured out how to distribute Jython and the Helper Library as an openHAB add-on, I would expect that this repo (or whereever the repo moves to once it becomes merged with OH proper) would follow the same branching and release approach as any other OH binding. Beyond releases though, I have no insight nor opinion on the proper approach for handling future work.

Installation of this library via git was only ever a stop gap solution until we could get it packaged up in a way that it can be installed via the OH add-on mechanism. It was never meant to be "the way it's done" forever.

[Confectrician]

It was never meant to be "the way it's done" forever.

I didn't expect that, but would like to have a comfortable solution until the bundle approach is done.
Maybe i will solve this with an own fork for now.