-
Notifications
You must be signed in to change notification settings - Fork 452
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
fix inital_volume being a string #778
base: master
Are you sure you want to change the base?
Conversation
unfortunately this is a breaking change, we could also change the readme to |
That is true but we don't need to publish a release instantly. Most people will use the latest stable version and this new way of parsing the "initial_value" will probably come with other minor breaking changes in the next version. |
yes that might be a good plan, the only thing just like the TOML pr is that people will copy the config from the readme, and that wont be compatible |
I added this to the next breaking change milestone. We should probably decide if we want to keep the incorrect documentation until then. |
We should update the documentation to work with the currently stable version and update it when we release the new version. We could probably just add a comment that with a git version of spotifyd, the value must be set differently. |
Or we could point the default branch to the latest release |
Yes I was thinking about this as well. Usually I'm not a fan of such a solution because it looks like nothing is developed anymore and most people see the master branch as nightly/latest version (as far as I noticed) but in such a case like this, it is probably a solution we should consider. |
Or we could just hold off on merging this until we're ready to release 0.4. |
Ye, just keep the PR open and merge once |
I noticed this and wanted to bring up changing the default branch to point to v.0.3.0, whereby drive-by readme readers could be shown the readme for the stable release and anyone looking to compile the master branch could do so with a simple That way, breaking changes could be included with a consistent readme in |
Alternatively, do we publish the book anywhere? It would probably make more sense if we had properly versioned documentation without expecting users to realize the cargo.toml is a year out-of-date, lol |
I'm not sure if you mean that, but the book is published here. It seems, however, that it is updated together with the master branch. Maybe we could
|
One could change this to be an enum with |
No description provided.