Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-30153

ad hoc client versions are confusing

Details

    Description

      While the version from client programs is rarely observed, sometimes its just used incorrectly like https://stackoverflow.com/questions/74601477/best-directory-for-data-exchange-between-php-and-mariadb-on-ubuntu to describe the server version.

      As these versions are never used without the compiled server version beside it, lets just drop the client version as the updating pattern for these at best is sparadic.

      Attachments

        Activity

          danblack Daniel Black created issue -
          danblack Daniel Black made changes -
          Field Original Value New Value
          Status Open [ 1 ] In Progress [ 3 ]
          danblack Daniel Black made changes -
          Assignee Daniel Black [ danblack ] Sergei Golubchik [ serg ]
          Status In Progress [ 3 ] In Review [ 10002 ]
          monty Michael Widenius added a comment - - edited

          I think it's a really bad idea to remove the independent version number from clients:

          • It is useful for a users and dba:s that moves between different servers to be able to check the client version when things doesn't work as expected in the client. For example, more commands, different options between CLIENT VERSIONS, not related to server versions at all!
          • A lot of your clients has come as contributions from different users. The authors are the one that should decide on the client version as they may change things independent of the server server version. We don't want to start changing version numbers to projects that we over time add to MariaDB (as forks), just like we don't do this with storage engines.
          • There are tools that we get as part of storage engine or plugins. I don't think it's a good idea to a version change of these. To change some things and not other things is more likely to lead to more confusion, not less.
          • Client tools can be backported to earlier versions, which adds new functionality to the tool. It is much easier to check the capability and functionality of a tool based on a single tool specific version number than have to div trough logs to see what was changed with a tool in a specific server version. Documenting client tools changes also becomes more complex if we have to list all server versions where a tool was changed.
          • OS, like Ubuntu and tools collections, like KDE, doesn't change the version number of their included tools. Why should we?
          • Just because a few users are confused about MariaDB client version is not any indication that there is any problem.
          • We have got very (any?) few reports about people being confused about our version numbers, which means that they are happy with the current state (or don't care). In either case, there is no reason to change versions.

          There are some packages that has changed all tools to just print the package version, like net-tools, gzip, coreutils. However this is not a good reason alone to change things.
          I don't think we (MariaDB developers) have any information of what users things about client/tool specific version numbers. Instead of doing a change based on one single users post, we should at least do some studying of the issue. Why not do some information gathering among our users to really understand what they think?
          We could do a questionnaire on the MariaDB foundation pages for example.

          monty Michael Widenius added a comment - - edited I think it's a really bad idea to remove the independent version number from clients: It is useful for a users and dba:s that moves between different servers to be able to check the client version when things doesn't work as expected in the client. For example, more commands, different options between CLIENT VERSIONS, not related to server versions at all! A lot of your clients has come as contributions from different users. The authors are the one that should decide on the client version as they may change things independent of the server server version. We don't want to start changing version numbers to projects that we over time add to MariaDB (as forks), just like we don't do this with storage engines. There are tools that we get as part of storage engine or plugins. I don't think it's a good idea to a version change of these. To change some things and not other things is more likely to lead to more confusion, not less. Client tools can be backported to earlier versions, which adds new functionality to the tool. It is much easier to check the capability and functionality of a tool based on a single tool specific version number than have to div trough logs to see what was changed with a tool in a specific server version. Documenting client tools changes also becomes more complex if we have to list all server versions where a tool was changed. OS, like Ubuntu and tools collections, like KDE, doesn't change the version number of their included tools. Why should we? Just because a few users are confused about MariaDB client version is not any indication that there is any problem. We have got very (any?) few reports about people being confused about our version numbers, which means that they are happy with the current state (or don't care). In either case, there is no reason to change versions. There are some packages that has changed all tools to just print the package version, like net-tools, gzip, coreutils. However this is not a good reason alone to change things. I don't think we (MariaDB developers) have any information of what users things about client/tool specific version numbers. Instead of doing a change based on one single users post, we should at least do some studying of the issue. Why not do some information gathering among our users to really understand what they think? We could do a questionnaire on the MariaDB foundation pages for example.
          monty Michael Widenius made changes -
          Status In Review [ 10002 ] In Testing [ 10301 ]
          monty Michael Widenius made changes -
          Status In Testing [ 10301 ] Stalled [ 10000 ]
          serg Sergei Golubchik made changes -
          Priority Major [ 3 ] Critical [ 2 ]
          serg Sergei Golubchik made changes -
          Status Stalled [ 10000 ] In Review [ 10002 ]

          monty I think these are potentially arguments towards putting the client tools into a separately maintained repo as well.

          TheLinuxJedi Andrew Hutchings (Inactive) added a comment - monty I think these are potentially arguments towards putting the client tools into a separately maintained repo as well.
          serg Sergei Golubchik made changes -
          Status In Review [ 10002 ] Stalled [ 10000 ]
          serg Sergei Golubchik made changes -
          Summary remove adhoc version from client programs ad hoc client versions are confusing
          serg Sergei Golubchik made changes -
          Status Stalled [ 10000 ] In Testing [ 10301 ]
          serg Sergei Golubchik made changes -
          Status In Testing [ 10301 ] Stalled [ 10000 ]
          serg Sergei Golubchik made changes -
          Assignee Sergei Golubchik [ serg ] Daniel Black [ danblack ]
          Status Stalled [ 10000 ] In Review [ 10002 ]

          An alternative to removing the version would be making it less likely to cause a confusion.
          Currently clients print

          mariadb Ver 15.1 Distrib 10.11.2-MariaDB for Linux (x86_64)
          

          we could change it to one of

          mariadb Ver 15.1-10.11.2-MariaDB for Linux (x86_64)
          mariadb Ver 15.1:10.11.2-MariaDB for Linux (x86_64)
          mariadb from 10.11.2-MariaDB (client: 15.1) for Linux (x86_64)
          

          or something along those lines

          serg Sergei Golubchik added a comment - An alternative to removing the version would be making it less likely to cause a confusion. Currently clients print mariadb Ver 15.1 Distrib 10.11.2-MariaDB for Linux (x86_64) we could change it to one of mariadb Ver 15.1-10.11.2-MariaDB for Linux (x86_64) mariadb Ver 15.1:10.11.2-MariaDB for Linux (x86_64) mariadb from 10.11.2-MariaDB (client: 15.1) for Linux (x86_64) or something along those lines

          After talking to monty, I've implemented

          mariadb from 10.11.2-MariaDB, client 15.1 for Linux (x86_64)
          

          serg Sergei Golubchik added a comment - After talking to monty , I've implemented mariadb from 10.11.2-MariaDB, client 15.1 for Linux (x86_64)
          serg Sergei Golubchik made changes -
          Status In Review [ 10002 ] In Testing [ 10301 ]
          serg Sergei Golubchik made changes -
          Assignee Daniel Black [ danblack ] Sergei Golubchik [ serg ]
          raysleepy Ray Sleepy added a comment -

          As a new user of MariaDB (and an on and off user of MySQL and *nix/Linux), I did find that "mariadb Ver 15.1" jumped out at me and confused me a bit. But "Distrib 10.11.2-MariaDB" was sufficient to assure me that I wasn't daydreaming..

          I feel that most users (even DBAs) of MariaDB have no direct need to think of mariadbd. They are not expected to interact with mariadbd directly, but rather systemctl mariadb start, service mariadb start, etc, so when they see mariadb, they would naturally associate it with the server.

          In a way, one could argue that it's "unfortunate" that the name of the client is the same as the database. e.g., sqlplus (oracle), sqlcmd (sqlserver), psql (postgresql), etc don't have this "issue." But it's neither here nor there..

          Anyway, adding the verbiage "client" is a very good idea to clarify that this is a client tool. It should definitely help decreasing confusion amongst inexperienced users.

          raysleepy Ray Sleepy added a comment - As a new user of MariaDB (and an on and off user of MySQL and *nix/Linux), I did find that "mariadb Ver 15.1" jumped out at me and confused me a bit. But "Distrib 10.11.2-MariaDB" was sufficient to assure me that I wasn't daydreaming.. I feel that most users (even DBAs) of MariaDB have no direct need to think of mariadbd. They are not expected to interact with mariadbd directly, but rather systemctl mariadb start, service mariadb start, etc, so when they see mariadb, they would naturally associate it with the server. In a way, one could argue that it's "unfortunate" that the name of the client is the same as the database. e.g., sqlplus (oracle), sqlcmd (sqlserver), psql (postgresql), etc don't have this "issue." But it's neither here nor there.. Anyway, adding the verbiage "client" is a very good idea to clarify that this is a client tool. It should definitely help decreasing confusion amongst inexperienced users.
          ramesh Ramesh Sivaraman made changes -
          Assignee Sergei Golubchik [ serg ] Ramesh Sivaraman [ JIRAUSER48189 ]
          ramesh Ramesh Sivaraman made changes -
          Assignee Ramesh Sivaraman [ JIRAUSER48189 ] Sergei Golubchik [ serg ]
          Status In Testing [ 10301 ] Stalled [ 10000 ]
          serg Sergei Golubchik made changes -
          Fix Version/s 11.0.1 [ 28548 ]
          Fix Version/s 11.0 [ 28320 ]
          Resolution Fixed [ 1 ]
          Status Stalled [ 10000 ] Closed [ 6 ]
          ralf.gebhardt Ralf Gebhardt made changes -
          Labels Preview_11.0

          People

            serg Sergei Golubchik
            danblack Daniel Black
            Votes:
            0 Vote for this issue
            Watchers:
            8 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Git Integration

                Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.