Releases 1.2.1 to 1.2.4 have the identical tag - mistake or correct?

[joerk]

Hi,

you have tagged release 1.2.1, 1.2.2, 1.2.3 and 1.2.4 with 1e37ed3. The start.sh will not get an release greater than 1.2.1. Is this correct?

Thanks joerk

------cut

pi@pi3:~/ct-Smart-Home $ git checkout master
Vorherige Position von HEAD war 1e37ed3 Update README.md
Zu Branch 'master' gewechselt
Ihr Branch ist auf demselben Stand wie 'origin/master'.
pi@pi3:~/ct-Smart-Home $ git pull
Bereits aktuell.
pi@pi3:~/ct-Smart-Home $ git rev-list --tags --max-count=1
1e37ed33c9faab3a1d1a9ab1278450bc656215b0
pi@pi3:~/ct-Smart-Home $ git fetch --tags
pi@pi3:~/ct-Smart-Home $ echo latestTag=$(git describe --tags `git rev-list --tags --max-count=1`)
latestTag=1.2.1
pi@pi3:~/ct-Smart-Home $ 

[merlinschumacher]

Hi,

that is correct. The tags only were created to update the docker images for Node-Red. A new tag triggers a rebuild of the images. In these cases there were upstream Node-Red updates, which have no direct effect on this repository. The tags are mostly a convenience feature to alert people of updates and to properly name the docker image tags.

[joerk]

Hi Merlin,

OK, I understand. Thanks. One final cross check before I close the issue. Your changes in the master branch e.g. added zigbeeadmin: - service to the docker-compose.yml is in development and not yet released? To use and test this stuff I checkout the master and have to use docker-compose directly or via VSC with the docker extension - the start of the start.sh resets all the files to 1.2.1 release version so the changes in my local repo are gone ... yes?

Regards joerk

[merlinschumacher]

I'm currently reworking the project structure so that the master will always be only the latest release version. If you change stuff in the files provided by the git repo, you should create a fork or stash your changes and reapply them on update.