v1.28.0 shows v1.29.0-dev; v1.27.x tags all having 149 commits to current

[swiffer]

Is there an existing issue for this?

• I have searched the existing issues

What happened?

Expected Behavior

Should show v1.28.0

Why are all v1.27.x tags are showing 149 commits compared to latest? have branches diverged?
https://github.com/teslamate-org/teslamate/tags

Steps To Reproduce

No response

Relevant log output

-

Screenshots

No response

Additional data

No response

Type of installation

Docker

Version

v1.28.0

[billerby]

Same here, also looks like the release action failed to publish the 1.28.0 image to docker.io (https://github.com/teslamate-org/teslamate/actions/runs/6988327850). Maybe related.

[rpearson-catdevnull]

See #3487. Think 1.28.0 has been marked as prerelease following that issue. Suspect once resolved should be fine

[swiffer]

Tags v1.27.1, v1.27.2, v1.27.3 and v1.27.4 are based of commits from v1.27 branch. That branch has never been merged back into master - therefore clicking on tagged versions in CHANGELOG.md / compare tags is giving "wrong" results currently...

e.g.
master...v1.27.3
v1.27.3...master
v1.27.4...v1.28.0

@JakobLichterfeld - Don't we have to merge v1.19 into v1.20, v1.20 into v1.21, ... v1.27 into master similar to how MariaDB is doing it?

https://github.com/MariaDB/server

-> EDIT: That doesn't fix tags historically - it should have been done before tagging new releases?

Afterwards - I guess it's fine to remove v1.X branches (or do we want to continue supporting several release branches at the same time)?

-> EDIT: Doesn't work, see comment below

[swiffer]

#3492

I would start like that - if you like I could to the other branches as well)

[JakobLichterfeld]

Good find, had observed it as well, will double-check tomorrow or on Monday.

[swiffer]

I don't see benefits in the branching model used up until now. It doesn't really look like we need to support multiple minor versions in parallel?

What has happened:

Whenever a new Minor Release is tagged a new Branch is created (e.g. v1.23). Changes happening afterwards (in master) have been cherry-picked into the release branches.

That means also those branches diverged from master but tags have been placed in these branches. Merging e.g. v1.20 into v1.21 now doesn't fix the the issue of not being able to compare tags correctly via git-diff

• Tags could be deleted and recreated on the master branch instead but we shouldn't do that.
• The moment we delete e.g. the v1.20 branch we are losing the tags, therefore we cannot do that either.

What should happen now:

It might be best to keep everything the way it is for the past and start working differently now (I would vote for having an ever-green master (and rename to main? :)) branch we are tagging new releases in and no longer create release branches).

Overusing Cherry-Pick results in a messy repo history: https://www.gitkraken.com/learn/git/cherry-pick#whats-the-difference-between-cherry-picking-and-merging-in-git

[JakobLichterfeld]

I don't see benefits in the branching model used up until now.

I could not agree more.

I would vote for having an ever-green master (and rename to main? :)

Same here. I do not have access to the settings to use the GitHub rename tool, otherwise I would have done it since weeks :-)

[swiffer]

@adriankumpf - could you rename master to main?

[JakobLichterfeld]

@adriankumpf - could you rename master to main?

@cwanja do have the rights as well I assume.

[oivindoh]

Renaming master to main seems a bit.. pointless?

[swiffer]

It's not giving direct value to Teslamate itself but it's git and GitHub defaults for reasons

https://www.theserverside.com/feature/Why-GitHub-renamed-its-master-branch-to-main

[cwanja]

@JakobLichterfeld - yes I have the ability to rename master (shocked I somehow do, but alas here we are). However, are they downstream net negative effects if I execute this? Or should it be performed in a controlled manner?

[cwanja]

Also, are we positive that 1.28.1 is safe to install now? Seen a handful of discussions and issues regarding it.

[swiffer]

Wait until Grafana Issues are sorted Out. I'll try to have a Look tomorrow morning...

[JakobLichterfeld]

@JakobLichterfeld - yes I have the ability to rename master (shocked I somehow do, but alas here we are). However, are they downstream net negative effects if I execute this? Or should it be performed in a controlled manner?

Perfect, saw your repo rights in a list. It is safe to do so, but we need to adopt our CI pipelines manually, so we need to coordinate it.

[oivindoh]

It's not giving direct value to Teslamate itself but it's git and GitHub defaults for reasons

https://www.theserverside.com/feature/Why-GitHub-renamed-its-master-branch-to-main

Wow that article contains quite the mental acrobatics reasoning, and this change will break people who link to / otherwise consume raw files from the master branch (such as dashboards) for no good reason.

[swiffer]

It's not giving direct value to Teslamate itself but it's git and GitHub defaults for reasons
https://www.theserverside.com/feature/Why-GitHub-renamed-its-master-branch-to-main

Wow that article contains quite the mental acrobatics reasoning, and this change will break people who link to / otherwise consume raw files from the master branch (such as dashboards) for no good reason.

Projects like Node.js have done it - most likely they had bigger implications...

However maybe it's best to Open a separate issue for that, Pin it, and give some Time ahead...

The topic of this issue have eben adressed

[cwanja]

@JakobLichterfeld - yes I have the ability to rename master (shocked I somehow do, but alas here we are). However, are they downstream net negative effects if I execute this? Or should it be performed in a controlled manner?

Perfect, saw your repo rights in a list. It is safe to do so, but we need to adopt our CI pipelines manually, so we need to coordinate it.

Let me know how you want to coordinate @JakobLichterfeld in light of the comments above 😄

[JakobLichterfeld]

However maybe it's best to Open a separate issue for that,

#3503