I have created a little program for myself (for home use) .
A now I am going to change it (to start to keep parameters in (and take its from) a text file (app.ini) , not in the source code)
And want to do it in serious style: assign next version (to practice my rust skills ).
Is it right way to create a new folder and manually change 'version = "0.1.0" ' to ' version = "0.2.0" ' in the cargo.toml ?
Or I have to use Cargo to do that ?
I do not use git. Excuse me, if there is an explanation in Rustbook.
The general way of doing this is pretty much what is described above. The bare-bones way of performing this process is to:
Increment the version number in your Cargo.toml file (following the conventions of SemVer)
Commit your changes and push to your repository
This step involves some type of VCS such as git
This step tends to vary a bit, depending on your preferred workflow
Publish the crate using cargo publish sub-command
This is the most straightforward and simple kind of workflow I can think of that will allow you to accomplish what you are trying to do.
If you'd like more information, there are other books provided on rust-lang.org, such as the Cargo reference, for example. From what I understand, you are referring to "The Book" aka "The Rust Programming Language". That is an introduction to the language itself and a fantastic starting point. What you're asking to do is slightly out of the scope of that book.
Edit: I do want to make sure that you don't shoot yourself in the foot later on down the road. If you're not already using some type of version control software (git is the most popular), you will definitely run into trouble. It may seem daunting at first, but it's really not as complicated as it seems. There are plenty of fantastic resources that can be found quite easily via doing a few internet searches. You only need to learn the basics to do what you're looking to do.
Best of luck! Please feel free to ask if you need clarification on anything I mentioned.
if you only want to use it locally, run cargo install --path . and you can already use it locally. If you have a lot to do, better learn git and cargo crates first.
I didn't use Git much before. But using Cargo, I felt like I'm being forced to use Git because Cargo won't work well with other VCS's (version control systems):
I switched my workflows to use Git, and even if I dislike to tell people what tools they should use: I would (currently) recommend everyone who works with Rust (or more precisely: Cargo) to use Git because using other VCS's comes with pitfalls when using Cargo.
I hope that Cargo will depend less on Git in the future, though I have become quite accustomed to Git in the meantime.
I'm afraid that the idiomatic way of doing things is to use Git.
Anyway, if you do not want to use Git, you could keep the different versions in different directories and just edit the version in the Cargo.toml file manually.
I guess it's also possible to not use Cargo at all (though I never tried that).
That said, I find Git horribly complex for beginners (at least if you want to really understand what's going on behind each of the sub-commands).
That said, if you are into these sorts of things, the Git source code is an absolute beauty to study - it is about as beautiful as C code gets. The user manual has a page to help you get started.
You may want to read the Pro Git book - I have found it to contain almost everything you want to know about Git to use it successfully.
I actually meant more the understanding from a user's perspective, particularly if you run into merge-conflicts, want to correct mistakes in your history, handling several remote repositories, fast-forward vs merging vs rebasing, etc. It's a lot to learn if you want to understand that. I haven't looked into the source at all yet, but maybe it could be interesting. Though… I'd also love a Rust based VCS. Last time I looked into Pijul, it wasn't well usable (reminded me of my experiences with Darcs).
My point is: I'd like to see something that's better than Git one day. But right now, Git seems to be the most robust choice.
Yes, I read it, and it helped me a lot! What confused me, however, is the comments on new commands available in recent versions of Git, like switch vs checkout, or restore vs reset etc. So many options and parameters.
Mercurial felt so much more easy (but can be a bigger pain when trying to clean up history or using branches).
(at least if you want to really understand what's going on behind each of the sub-commands).
).