Details

    Description

      There's too many old and new people referring to MariaDB as MySQL. We need to encourage the transition in naming.

      Because mariadb names have began in 10.4, lets step up the conversion process by adding a deprecation notice on mysql names.

      There may be some people that want to use previous names scripts, we'll add an environment variable to suppress the warning (wasn't implemented)

      Attachments

        Issue Links

          Activity

            danblack Daniel Black added a comment - - edited

            serg, ralf.gebhardt, what do you think? Time do deprecate mysql* names with a warning? (pull request 2273)

            danblack Daniel Black added a comment - - edited serg , ralf.gebhardt , what do you think? Time do deprecate mysql* names with a warning? (pull request 2273)
            elenst Elena Stepanova added a comment - - edited

            Where would this warning be printed, and when? Is it like, whenever I say mysql --version in the command line, an extra line would pop up in the output, etc.?
            I imagine it would break countless scripts around the world.

            Upd: missed the "pull request" part, and yes, it seems that's pretty much what it does.

            elenst Elena Stepanova added a comment - - edited Where would this warning be printed, and when? Is it like, whenever I say mysql --version in the command line, an extra line would pop up in the output, etc.? I imagine it would break countless scripts around the world. Upd: missed the "pull request" part, and yes, it seems that's pretty much what it does.
            ralf.gebhardt Ralf Gebhardt added a comment -

            danblack, too late for 10.11 but I agree, we should prepare the next step of the conversion process still in 10.x.
            maxmether^^

            ralf.gebhardt Ralf Gebhardt added a comment - danblack , too late for 10.11 but I agree, we should prepare the next step of the conversion process still in 10.x. maxmether ^^

            No warning, please.
            According to the plan, the next step after MDEV-21303 was supposed to be — put all aliases in a separate package (may be several separate packages), like, MariaDB-client-aliases (or -compat). But still install it by default.

            And the next step ­— don't install it by default.

            serg Sergei Golubchik added a comment - No warning, please. According to the plan, the next step after MDEV-21303 was supposed to be — put all aliases in a separate package (may be several separate packages), like, MariaDB-client-aliases (or -compat). But still install it by default. And the next step ­— don't install it by default.

            "And the next step ­— don't install it by default."

            This part is a breaking change that will irritate users who aren't aware it is coming. I know, they should read the docs, changelog, etc... But you know that doesn't always happen.

            If we don't deprecate first using a method people will notice with something like the PR, then we will cause issues. Doing the step PR gives us an avenue for that.

            TheLinuxJedi Andrew Hutchings (Inactive) added a comment - "And the next step ­— don't install it by default." This part is a breaking change that will irritate users who aren't aware it is coming. I know, they should read the docs, changelog, etc... But you know that doesn't always happen. If we don't deprecate first using a method people will notice with something like the PR, then we will cause issues. Doing the step PR gives us an avenue for that.

            As an added point, we shouldn't be concerned about breaking scripts by having stderr output. Particularly in a major version change where you would have to revalidate your scripts anyway.

            TheLinuxJedi Andrew Hutchings (Inactive) added a comment - As an added point, we shouldn't be concerned about breaking scripts by having stderr output. Particularly in a major version change where you would have to revalidate your scripts anyway.
            ralf.gebhardt Ralf Gebhardt added a comment -

            With this change we also need to look at the user experience to install MariaDB Server, docs, scripts, ..s

            ralf.gebhardt Ralf Gebhardt added a comment - With this change we also need to look at the user experience to install MariaDB Server, docs, scripts, ..s

            To comment on the https://github.com/MariaDB/server/pull/2273/commits/3745ebdd9b77eaa79f98dda274a7636c26874f94:

            1. For users it's not about pride, don't use this word anywhere. We merely warn users that eventually mysql* compatibility symlinks will go away, as MariaDB and MySQL keep diverging and we do not want to make it impossible to install MariaDB and MySQL side-by-side when users want it.
            2. make mysql* compatibility symlinks optional. No need to do it in bintars, but it should be possible to install MariaDB from rpm or deb packages without symlinks.
            serg Sergei Golubchik added a comment - To comment on the https://github.com/MariaDB/server/pull/2273/commits/3745ebdd9b77eaa79f98dda274a7636c26874f94: For users it's not about pride, don't use this word anywhere. We merely warn users that eventually mysql* compatibility symlinks will go away, as MariaDB and MySQL keep diverging and we do not want to make it impossible to install MariaDB and MySQL side-by-side when users want it. make mysql* compatibility symlinks optional. No need to do it in bintars, but it should be possible to install MariaDB from rpm or deb packages without symlinks.
            Eric_Herman Eric Herman added a comment -

            I fully support making the links optional. Dropping them from the default, is likely to lead to a break. Rather than emit warning messages, I'd like to see thought put into the version numbering.

            I'd like to avoid the kind of surprises that we had with the change of the user tables: I was surprised that I had to change an automated install procedure, something I didn't expect upgrading within the 10.x series, which I expected to only add stuff, not break a workflow.

            We can argue about what should truly constitute the user-space API, but if a reasonable person can be negatively impacted by a surprise change, this argues that perhaps it's not a "minor" version change, but a "major" one.

            If these script name changes make it feel like perhaps it's a "major" upgrade, then https://mariadb.com/kb/en/version_major/ and semver.org would indicate that we should increment the first digit.

            Eric_Herman Eric Herman added a comment - I fully support making the links optional. Dropping them from the default, is likely to lead to a break. Rather than emit warning messages, I'd like to see thought put into the version numbering. I'd like to avoid the kind of surprises that we had with the change of the user tables: I was surprised that I had to change an automated install procedure, something I didn't expect upgrading within the 10.x series, which I expected to only add stuff, not break a workflow. We can argue about what should truly constitute the user-space API, but if a reasonable person can be negatively impacted by a surprise change, this argues that perhaps it's not a "minor" version change, but a "major" one. If these script name changes make it feel like perhaps it's a "major" upgrade, then https://mariadb.com/kb/en/version_major/ and semver.org would indicate that we should increment the first digit.

            Eric_Herman, right. Dropping links from the default installation is definitely not part of this task.

            serg Sergei Golubchik added a comment - Eric_Herman , right. Dropping links from the default installation is definitely not part of this task.
            ralf.gebhardt Ralf Gebhardt added a comment -

            I agree, dropping links (and other mysql->mariadb replacements) should be a 11.0 task

            ralf.gebhardt Ralf Gebhardt added a comment - I agree, dropping links (and other mysql->mariadb replacements) should be a 11.0 task

            see the latest version in the bb-11.0-serg branch

            serg Sergei Golubchik added a comment - see the latest version in the bb-11.0-serg branch

            OK to push. However, in the end no environment variable to suppress warnings was implemented, so this should be reflected in the ticket description and any documentation.

            angelique.sklavounos Angelique Sklavounos (Inactive) added a comment - OK to push. However, in the end no environment variable to suppress warnings was implemented, so this should be reflected in the ticket description and any documentation.

            serg Please remove this message or make conditional:

            /home/midenok/src/mariadb/10.6/build/opt/bin/mysqld: Deprecated program name. It will be removed in a future release, use '/home/midenok/src/mariadb/10.6/build/sql/mariadbd' instead
            

            Who does need it? Packages contain the right name. Everybody else can figure out themselves when that happens. These kind of nagging messages do not do any good but take attention each time that happens (a lot!). At least some environment variable PLEASE_DO_NOT_NAG_ME should be made.

            midenok Aleksey Midenkov added a comment - serg Please remove this message or make conditional: /home/midenok/src/mariadb/10.6/build/opt/bin/mysqld: Deprecated program name. It will be removed in a future release, use '/home/midenok/src/mariadb/10.6/build/sql/mariadbd' instead Who does need it? Packages contain the right name. Everybody else can figure out themselves when that happens. These kind of nagging messages do not do any good but take attention each time that happens (a lot!). At least some environment variable PLEASE_DO_NOT_NAG_ME should be made.

            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.