add binary file name in new release option

[hyperion-cs]

Sometimes it is necessary to manually specify the name of the binary file in a new release (in which case, the target name and path will stay the same as for the "current" (old) executable). This PR implements this feature.

There are some breaking changes in the public API, so it's better to make a new minor version — v1.6.0.

[codecov]

Codecov Report

❌ Patch coverage is 90.00000% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 77.10%. Comparing base (eb6d9af) to head (abd7f72).

Files with missing lines	Patch %	Lines
package.go	66.67%	2 Missing ⚠️
update.go	75.00%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #55      +/-   ##
==========================================
+ Coverage   76.95%   77.10%   +0.15%     
==========================================
  Files          28       28              
  Lines        1167     1166       -1     
==========================================
+ Hits          898      899       +1     
+ Misses        218      217       -1     
+ Partials       51       50       -1     

Flag	Coverage Δ
unittests	77.10% <90.00%> (+0.15%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[hyperion-cs]

@creativeprojects, is there anything else I need to do here?

[creativeprojects]

Hi, thank you for this PR

It's a good idea actually 😄

It's changing the signature of the exported methods. It means it's a breaking change: so it's not going to be a v1.6.0. but a v2 🤔

[hyperion-cs]

@creativeprojects oh, it looks like you're right. At the same time, updating the major version just for such a minor change is probably a bad idea. In that case, I suggest two options:

1. Keep the old signatures of existing exported methods as they are to avoid breaking backward compatibility. In addition to these, create new ones. At the same time, all existing methods will use the new signature with a default value of relExe, something like:

   func (up *Updater) UpdateToNew(ctx context.Context, rel *Release, relExe, cmdPath string) error { ... }
   
   func (up *Updater) UpdateTo(ctx context.Context, rel *Release, cmdPath string) error {
       _, relExe := filepath.Split(cmdPath)
       return UpdateToNew(ctx, rel, relExe, cmdPath)
   }

   In that case, we'll need to decide which suffix to use for the new methods (and mark the old ones as "soon to be deprecated").

2. Really think about a new major version, 2.0.0, but reconsider the parameter concept for exported methods. In each public method, create a structure that stores the parameters. This will allow us to add new fields (parameters) without breaking backward compatibility. I’m talking about replacing old methods like:

   func (up *Updater) UpdateTo(ctx context.Context, rel *Release, cmdPath string) error { ... }

   To something like:

   type UpdateToOpt struct {
       Ctx context.Context
       Rel *Release
       CmdPath string
   }
   
   func (up *Updater) UpdateTo(opt UpdateToOpt) error { ... }

   It is important to note that expanding the method's options (parameters) no longer breaks backward compatibility, because they can now have default values. In addition, there will be no performance hit, since UpdateToOpt (and similar methods) are stack-based.

---

Overall, I can help with any of these options. What do you think?

[creativeprojects]

Option 2 looks quite neat.
There's a convention of not putting a context into a struct, so the signature would be more like:

type UpdateToOpt struct {
    Rel *Release
    CmdPath string
}

func (up *Updater) UpdateTo(ctx context.Context, opt UpdateToOpt) error { ... }

[hyperion-cs]

@creativeprojects okay, I'll take care of it.

[hyperion-cs]

@creativeprojects I replaced parameters to options in all the major export methods/functions in a5c57b2. What do you think?