Presupposes accepting patch for adopting YAML info-file format:
#1793074-80: Convert .info files to YAML

The proposal is to use a static format filename for the new info-file, rather than the historic variable format that varied with the module name (ie. modulename.info)

Related conversation from linked thread:

@sun originally raised a concern in #75 about the variable format's false positives when drupal was simply looking to parse any YAML files.

@cweagans reiterated the valid concern in #83, that static format would be cumbersome when multiple info-files are open in the editor.

As @sun mentioned in #84: static format might act as a trivial way to enforce one-module-per-directory.
Reference issue: #1299424: Allow one module per directory and move system tests to core/modules/system

@tstoeckler had this to say in #89:

I also agree with #84, but until themes are actually full extensions (#1067408: Themes need an installation status), and we actually have the concept of extensions in core (#1331486: Move module_invoke_*() and friends to an Extensions class), I think it would make sense to go with module.yaml for now, instead of extension.yaml. Since the latter would also require parsing each file to know it is a module (and introducing a type key for that purpose), I would consider that feature-creep, even it is the intended goal in the end.

Comments

patcon’s picture

Title: Rename modulename.yml to static filename like module.yml / extension.yml » Move info-file from variable format (modulename.yml) to static format (module.yml / extension.yml)

Clearer topic.

cweagans’s picture

I've already expressed my distaste at this approach in the other issue, so I'll just leave it at this:

-1

Pancho’s picture

Category: feature » task

I agree that this doesn't seem to be a good idea.
If #1398772: Replace .info.yml with composer.json for extensions makes a static filename unavoidable and still is the right way to go, then be it. But otherwise, duplicate filenames really aren't nice in editor tabs. I know that such are common in other projects, but that's nor reason to unnecessarily make our codebase harder to maintain.

Actually I don't even see a compelling reason to do it:
The current naming proposal in #1793074: Convert .info files to YAML avoids false-positives, so this argument is ruled out.
And if we feel enforcing the one-module-per-directory rule (#1299424: Allow one module per directory and move system tests to core/modules/system) is necessary, then this should be the subject of this issue and we need to evaluate the best way to accomplish it.

sun’s picture

Status: Active » Postponed
mgifford’s picture

Status: Postponed » Active
Related issues: +#1793074: Convert .info files to YAML
cweagans’s picture

Version: 8.0.x-dev » 9.x-dev
catch’s picture

Version: 9.x-dev » 8.1.x-dev
Status: Active » Postponed

We could support this for forward compatibility in a late 8.x minor release.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.