[MAGNOLIA-6339] Find better module (display) name for magnolia-configuration Created: 13/Aug/15  Updated: 02/Oct/15  Resolved: 02/Oct/15

Status: Closed
Project: Magnolia
Component/s: configuration, resource-loader
Affects Version/s: 5.4
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: Natascha Desmarais Assignee: Mikaël Geljić
Resolution: Won't Fix Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Date of First Response:

 Description   

Right now the module magnolia-configuration is installed as config. This seems an infortunate name that might cause confusion to its purpose, especially as it does not contain any configurable items (so far) in AdminCentral.

  • It has nothing to do with the config workspace itself, but one could think so ( config:/modules/config )
  • It also does not contain the configuration app
  • Quite some modules contain a config node - one could deduct a dependency to this as well.

Not sure what to suggest there, but maybe something along the lines of

  • configurators (maybe also still a bit too ambiguous)
  • configurator-sources
  • configuration-sources
  • config-api
  • config-framework


 Comments   
Comment by Christian Ringele [ 13/Aug/15 ]

I would prefer to have changed not just the display name, also the real installed module name in config:/modules

Comment by Mikaël Geljić [ 23/Sep/15 ]

Hi you two!
I agree config-framework would have been a more fortunate choice... if only we had realized before the 5.4 release.
The most problematic part I see now: communication for developers who might already have a module dependency to it.

If we changed it, it would be a choice between:

  • "the earlier the better"
  • "only in 5.5 because one doesn't change dependencies arbitrarily during maintenance"
  • "never", because it's pretty far from critical (unlike many other things, unfortunately)

Raise it if you do feel strongly about it, or if you have concrete ideas to help making this smoother.
Meanwhile I may have to close this ticket :/.

Cheers,

Generated at Mon Feb 12 04:13:35 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.