Display of the version and Config on the website

[chkbln]

Hello,
It would be possible to display the version of McLighting on the website.
Or a separate page with changes.
Then I remember one could also show the config. (Number of LED, data pin, etc.)

Best regards

[debsahu]

What do you mean by version?

[chkbln]

here's an example
https://github.com/arendst/Sonoff-Tasmota/blob/development/sonoff/_releasenotes.ino
That could be displayed on a separate website.
You can see directly what options are available on the ESP8266.

[toblum]

Hi @chkbln,

do you mean the release notes?

I fact, both (version and detailed release notes) are not available at the moment. Just the notes on the front page and no real versioning.

But this is something I have already thought of, but didn't find the time to do (as with many things at the moment).

Luckily for me @debsahu is helping me a lot at the moment and provides many new functions and fixes. So we have many changes at the moment and some kind of versioning would help to keep up with it. What do you think @debsahu?

Regards
Tobias

[debsahu]

Absolutely, I agree. I try to put as much information in pull requests as possible. How do you increment versions? v2.1 to v2.2... I don't know the ethics/standards/reasons for an increment.

[toblum]

Hi @debsahu,

I saw that you always have detailed informations ind the PR, so the best idea would be to just copy these over to a "release_notes.md" file in the project root and add a version there. We could think about putting this version also in the definitions.h and return it with /status. This may help with the support also.

About the versioning schema I would suggest to use a simple version of semantic versioning https://semver.org/ (MAJOR.MINOR.PATCH).

• MAJOR increases only for really big changes.
• MINOR if there are new funtionalities or config options available, that need maybe attention
• PATCH only for fixes that do not change/break anything for existing users.

Maybe starting now with 2.1?

[debsahu]

Thank you for the detailed information. Again do you want to get rid of (delete) so many branches and stick with master and devel? Protect the master branch and we can work on devel. This way I dont have to work on my branch and pull here.

[chkbln]

Hi
Yes, I mean the release notes.
Due to the many changes you sometimes do not know which version you have flashed. The release notes with the associated versioning would help.
I feel understood by you.

What I would like to suggest is the display of the parameters specified during compilation. Number of LED, Which MQtt protocol. (Normal or asynchronous) etc. So the parameters I have been adjusted in the definitions.h accordingly.

I can understand that there is a lack of time. Nevertheless many thanks that the project continues.

greetings

[toblum]

Hi @debsahu,

sure, we could kick some branches, especially the ones just created for features. The only one I would keep is the "artnet" one, because it is not yet part of the master. All others should be integrated into master in the meanwhile. Feel free to delete, if you want. Then working in "development" (with additional feature branches if it makes sense) sounds like a good idea.

[toblum]

@chkbln Thanks for your suggestions, I added this to the ToDo list.

Best regards
Tobias