Redmine

+1

Since it is not possible to change the text formatter setting for each project in Redmine, there is also the problem that it is difficult to change to Markdown once you start using it with Textile.
I think it's better to use the commonly used Markdown as the default.

+1

Markdown is used in many text systems (GitHub, Slack, ...etc). Therefore, setting this as the default will improve portability.

+1

Since it is not possible to change the text formatter setting for each project in Redmine, there is also the problem that it is difficult to change to Markdown once you start using it with Textile.
I think it's better to use the commonly used Markdown as the default.

it's possible using grep, sed, and pandoc. but it's a real PITA

+1

Markdown is also the better choice for the 'average guy' and has easier to adopt by non IT people.

Now that CommonMark feature was added to the core, for sure we should not set the old Markdown as default, but at the same time, it's pity to keep textile as default.

Maybe is better to set CommonMark even is it marked as experimental? Or even remove the experimental flag?

When changing the default formatter, we should ensure that the previous setting is definitely preserved. Often, the setting is stored in the database, but not necessarily. It can also be used with just the default from settings.yml. Changing the setting just there will silently change the global text formatting setting during an upgrade.

As such, I believe we need a migration here that strictly adds the current setting as a database entry before changing this (rather important) default setting. This must take several cases into account:

• Upgrade - An existing Redmine with a text_formatting setting stored in the database
• Upgrade - An existing Redmine with the default text_formatting from settings.yml without an explicitly stored setting
• New Setup - An initial setup with an empty database.

A possible solution would be to perform the following two changes:

• Add a new migration which sets the text_formatting setting in the database to the static value textile, only if there is no existing entry in the database.
  This should take care of the upgrade paths to retain the previous (default or adapted) setting regardless of how we change the default in settings.yml.
• Update an existing old migration to explicitly set the common_mark setting to the database in the same commit as the update to the settings.yml. E.g. the source:trunk/db/migrate/017_create_settings.rb migration.
  This should take care of the initial setup. As the new default setting is set to the DB early, the later new migration will no nothing in this case. Existing installation won't re-apply the changed initial migration.

As for the timeline, please let me quote my comment from #36807#note-5:

The default formatter is only relevant for new installations. I have no strong opinion on whether this requires a major release (6.0.0) or minor release (5.1.0). I have a slight hunch that it might be surprising in a patch release (5.0.x).

In an existing installation without a setting in the database, when applying the patch and then running the migration, Setting.text_formatting will already return common_mark with the changed default in settings.yml.

I think the migration should set the value in the database literally to textile (as Holger suggested) in case no setting is present, to persist the previous default.

(Edit: Of course in that case Holger's second point, changing the create_settings migration in the same commit to reflect the new default for fresh installations, is necessary as well)

You're right Jens, I didn't see this point. Thanks both for your feedback on this.

I'm going to update the patches in the following days.