Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Please follow semantic versioning - don’t break my build #631

Closed
iCodeSometime opened this issue Oct 9, 2024 · 2 comments
Closed

Please follow semantic versioning - don’t break my build #631

iCodeSometime opened this issue Oct 9, 2024 · 2 comments
Labels
enhancement New feature or request

Comments

@iCodeSometime
Copy link

What would you like to be added?

Please follow semantic versioning.

If the public API is changed, it must not be distributed as a minor release.

Why is this needed?

For three months in a row now, there have been breaking changes to the public API of this action that were distributed as a minor release.

I and my teammates have wasted a significant number of hours tracking down why things have broken, only to realize there’s been a significant change to the behavior of this action, with no major version bump.

@joshmgross
Copy link
Member

#590 and #630 have been fixed and were not intentional breaking changes.

#602 fully details why we made the decision to ship a breaking change.

@joshmgross joshmgross closed this as not planned Won't fix, can't repro, duplicate, stale Oct 23, 2024
@Paebbels
Copy link

Paebbels commented Dec 5, 2024

You could have´:

  1. release a v5 with the breaking modification
  2. made v4 print a deprecation message for 2..4 weeks
  3. disabled v4

Also keep in mind, hidden files in Linux are widely used for settings, but barely hold any secret information. There is almost no security risk to these files, especially as we're talking about Git repositories with local editor or tool configs. Also dot-files are usually not created in a CI job; the pre-exist in the repository itself. Thus, if these files contain secrets, the secret was already exposed by sharing the files in a repository itself.

In my opinion, this was a complete overreaction by GitHub without understanding the problem and the implications.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants