-
Notifications
You must be signed in to change notification settings - Fork 174
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
Implement tag
command
#525
Comments
I guess having nimble editing the .nimble file is a no-no? It would be convenient if one command would do all the bookkeeping needed for a release - updating nimble,making the tag and pushing the repo all in one go. |
Problem with that though is that the nimble file is NimScript and IIRC you can do things like |
Let's add this command feature ASAP. All other package libraries I know of do this sort of tagging as part of $ nimble bump patch # increase version by `0.0.1` and run `nimble tag`
$ nimble bump minor # increase version by `0.1.0` and set patch version `0`, then run `nimble tag`
$ nimble bump major # increase version by `1.0.0` and set patch + minor version `0`, and run `nimble tag` I'll give it a go |
I added initial support for the tag command here. Currently only supports Tag repo and push tags to remote repo $ nimble --tag 0.1.0 Increase patch version tag and publish (ie. 0.1.2 to 0.1.3) $ nimble publish --tag patch
# shorthand alternative
$ nimble publish --tag . Increase minor version tag and publish (ie. 0.1.2 to 0.2.0) $ nimble publish --tag minor
# shorthand alternative
$ nimble publish --tag m Increase major version tag and publish (ie. 0.1.2 to 1.0.0) $ nimble publish --tag major
# shorthand alternative
$ nimble publish --tag M The increase tag variant works for the tag command as well: $ nimble tag --tag M Perhaps the option should be renamed |
Now uses bump under the covers. |
Main feedback is that you cannot depend on bump as a package since nimble is the package manager and you cannot install bump before nimble is built. |
At this point, why don't we just make |
We could just execute
Would make it much easier to implement and stay in sync with bump functionality |
I've implemented a new version of this feature where I've removed the dependency on Needs testing, unit testing (tmrw?) and review. Likely the options format need to be agreed on for optimal UX Should I open a PR to work from? |
Yes, again, I'd like a generic solution where packages can provide binaries named |
Please don't. Either make "bump" a real feature of Nimble or stay out of bump's way. "Every command must start with nimble-" doesn't add any usability whatsoever. |
@Araq I also recommend keeping nimble dependency free. My latest commit has no dependencies. |
Huh? It obviously adds usability, it would make these kinds of features trivial. |
@dom96 - main push back from me is that Options:
cc @disruptek |
I don't really have much of an opinion, except that it seems completely irrelevant to the compiler and probably even orthogonal to the distribution. Pulling it into I think dynamic subcommands are a cute feature, but only if the parent and child apps actually benefit from the integration. I don't really see that here, but maybe you guys have a good idea that hasn't occurred to me. For example,
...and so on... |
As I said in IRC, I'm flattered that Kristian took the time on this PR. I also think the fact that his time is now costing us time and creating pushback is absurd. Let's close this PR with apologies. I agree with @dom96 that automatic subcommand extensions makes sense. It lets subcommands develop independently, removes friction from the ecosystem, and stifles duplication of effort like this. Let's also make a way to query nimble for its available subcommands and include their (abbreviated) |
Thanks for the thumbs up. Please know that the PR has not been fully tested and is mainly a POC. I'm still very new to the Nim ecosystem, so perhaps better that someone take charge, test + polish it, to finalise this PR. How about the CLI arguments? should it be --bump patch or perhaps use tag or version? |
This push back doesn't make sense to me. If |
I think it would be a great idea to integrate Sub-commands would likely be the way forward, as it opens up more flexibility. Perhaps some of the other commands should use sub-commands as well? In terms of requiring pre-existing installation of bump that would make it much easier to do obviously and bump could then evolve independently. Let's try it. Much easier pathway than building new functionality or integrating bump directly into the core of nimble. Your thoughts? |
If nimble instead maintains a list of known subcommands, when a user runs So no need to changes Next question is when nimble should update an existing install of |
If that question is aimed at me then you should already know my answer: yes, I would prefer to keep Nimble simpler and allow its evolution via external commands.
This approach doesn't scale. One thing we can do is mark packages providing a binary that Nimble can call with a But this is something that can come after, it's an additional feature that makes discovery better, but it's not necessary. Let's focus on the basics first. For a basic implementation I think a
I don't think we should worry about this for now. This is another feature that is much further in the future and we can cross that bridge when we come to it. |
Related to #433 which is the generic requirement. |
Usage:
nimble tag v0.1.1
Nimble will run
git tag v0.1.1
(or equivalent) and verify that the package's .nimble file has been updated with that version.Bonus feature:
The text was updated successfully, but these errors were encountered: