fix readme

[eryajf]

#144 (comment)

[eryajf]

I temporarily removed the corresponding instructions and put the correct version into README. At least until better changes are made, what people see through README is available.

[mre]

FYI v1 points to the latest master again.

[tooomm]

FYI v1 points to the latest master again.

Not sure you got it right. It shows v1.0.0 from December 2020 as the latest now. 🙈

This is trickier than expected, haha.

[eryajf]

Not sure you got it right. It shows v1.0.0 from December 2020 as the latest now. 🙈

I just ran a test with v1 and it worked normally. This is feasible

https://github.com/eryajf/learn-github/runs/7778974334?check_suite_focus=true

[tooomm]

It works, yes. But the list of releases is messed up now.

There must be another way when you look at other actions that support this.
Maybe a setting in the marketplace?

[tooomm]

It seems like there are some open questions or confusion still. @mre

FYI v1 points to the latest master again.

@v1 should not target master, but always the newest available v1.*.* release automatically (v1.5.1 currently).
There is @master for targeting master already.

I think it works for peter-evans/create-issue-from-file, maybe @peter-evans himself can help with the correct marketplace and release setup to get moving releases like v1 for the lychee-action as well? I did not find something useful via google. 🙈

Peter, once you release a v4.0.1 version, you do tag it as such and everybody using v4 should automatically start using it. Is there anything to setup in particular to make it work like that (marketplace, repo, releases...)?

[peter-evans]

I release using the GitHub releases UI and set the version to the full vx.x.x format. I then use git commands to move the major version tag from the previous release commit to the new release. The major version tag is not associated with any specific GitHub release. I manage it manually with git.

[mre]

Just a quick update: it worked. Thanks for the description @peter-evans.

Here's what I did for the latest release:

• Created a new tag through the Github releases UI
• Tagged v1 manually on the CLI: git tag -f v1 v1.5.2
• Pushed the new tag: git push -f origin v1

My original mistake was that I tagged v1 to master, which had a newer commit than the latest point release. As a result it would show up on top of the list. Now that v1 and v1.5.2 point to the same commit v1 wasn't pushed to the top anymore.