-
Notifications
You must be signed in to change notification settings - Fork 5
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
RFC 1001: Update vs upgrade #8
Comments
I still think that keeping it in the install makes sense:
|
I'd like to add a few words In defence of calling an update to the latest minor version a "patch". This procedure effectively gets you the latest patches to your current version, overwriting it. It is not possible to install several minor versions in parallel, so again, they are more like patches of a fundamentally same entity. They also don't require any fuss with data. Whereas major version upgrades are none of these things: major versions can coexist in parallel and they may require doing something to the data. Rule of thumb is that you generally want to get patches ASAP, but may not necessarily want an upgrade in most software products and it seems to me that minor and major versions work like that for edgedb, too. |
@vpetrovykh I agree with what you're saying. But I'm not sure that "patch" as a software update makes a lot of sense for developers who recently joined the field. |
For the record, my suggestion for this was as follows: e s install
e s upgrade
e s list [installed]
e s list available
Why I think this is a good ideaHaving one way to upgrade instances is safe. People won't run the wrong thing. And if they did mean --major and ran --minor by mistake, no foul, that should be entirely compatible. Plus, the tool will tell you that there's an available major upgrade path. Having commands that only do one thing is easier to understand. It avoids combinations of arguments which don't make sense. It helps users state intent better. When they install a new vesion, the tool will tell them that this action did not upgrade their instances. They just have more versions available. Other unsolved questions
I'm leaning towards yes but wanted to highlight this. |
I actually like @ambv's approach, it makes sense to me. I would add an option to do selective per-instance |
Admit it, you just liked my masterful use of Markdown. But yeah, we should do selective --major upgrades, that makes sense to me. |
Guilty as charged 😉 |
Also 1 to @ambv's way.
This is the key. Having two separate commands to update to minor and to major seems confusing to me. |
OK, so it seems we have emerging consensus. I'll amend the RFC accordingly. |
There are two concerns that RFC 1001 covers:
The process of updating the installed server packages, which is done via
edgedb server install --update
in the current version of the RFC.The process of upgrading an EdgeDB server instance (i.e a data directory) to a new (major) EdgeDB version, which is done via
edgedb server upgrade
in the current version of the RFC.@ambv pointed out that a lot of the options in
edgedb server install
do not actually apply to the--update
mode (e. g. you cannot do--docker --update
if the initialinstall
was ran without--docker
). Hence, the suggestion to have a separate command for installed package updates:edgedb server update
. That, however, is very close toedgedb server upgrade
and would be an endless source of confusion. Another idea from @vpetrovykh is to name the package update command asedgedb server patch
.Also, worth noting that
edgedb server install --update
is intended to update the installed package to the most recent minor version for a given major version.Open questions:
install
?server upgrade
withinstall
andupdate
?The text was updated successfully, but these errors were encountered: