Fix version

[marksartdev]

Excellent tool.

But it will be better, if I can fix particular version for particular binary.

For example: I have foo@1.2.4, bar@3.2.1, cool@3.3.3.

I want update all bins except foo. I want to call something like this go-global-update --exclude foo or go-global-update --fix foo@1.2.3.

[Gelio]

Thanks for your feedback!

Having such a way to exclude a binary from being updated seems like a worthwhile feature.

I was immediately thinking whether this should be something permanent (you call go-global-update --exclude foo and that puts foo into some exclude file which is consulted during each next go-global-update), or one-time only (you must specify --exclude each time).

I'm leaning towards having a list of ignored binaries in some config file, since I reckon that would be a more common use-case.

I would probably name it --lock, since, to me, this is about locking a specific version of the binary (if we follow the persistent config approach).

EDIT: alternatively, this option could be called --pin, since it pins the version. I guess we should do more research on how other package managers name this feature.

What are your thoughts?

[marksartdev]

Hello @Gelio,

Thank you for answer. In my opinion, adding version to lock list is a good idea. But I think, using sub command lock is better than using parameter, because it is not a customization of updating. It is another operation (it is addition version to lock list).

In my option, this sub command will be great:

go-global-update lock foo@v1.2.3

And it will be great to have ability to lock major, minor or patch versions. For this purposes you can use parameters:

go-global-update lock foo@v1.2.3 # for patch version
go-global-update lock --minor foo@v1.2 # for minor version
go-global-update lock --major foo@v1 # for major version

[Gelio]

Right, and that, unfortunately, would be a breaking change, since right now, there are no subcommands for go-global-update. It has flags, and any arguments that come after are binary names.

Perhaps it's fine to make such a breaking change by introducing subcommands to go-global-update. Alternatively, we could have a separate go-global-update-lock command (or something like that) for controlling the lockfile 🤔

[marksartdev]

We can add subcommands and use run subcommand as default. It means that call without any subcommands will equal go-global-update run with passing all flags to subcommand.

go-global-update --dry-run will equal go-global-update run --dry-run. And also we can add go-global-update lock foo@v1.2.3.

It can be implemented by https://github.com/spf13/cobra.

If you want, I can help with subcommands.

[Gelio]

Right, that's a possible approach. I am still not sure about making this breaking change vs adding a new command to manage the lockfile. Especially since the lockfile is optional. Perhaps someone else will come here and have an opinion.

It can be implemented by https://github.com/spf13/cobra.

go-global-update is already using https://github.com/urfave/cli which supports commands.

[marksartdev]

It is not a breaking changes. It will still work as before, because new command run will be default command. It means that executing go-global-update will work as before.