Is there a naming strategy for new projects?

  • Page Owner: Not Set
  • Last Reviewed: 2018-08-30

It looks like we choose an arbitrary name followed by -{stack}. Is that correct? Can we outline how we choose the project name and stack names?

Should Drupal 7/8/9 be named the same (foo-d7 or foo-drupal)?

Comments

  • Not sure where you're seeing those names.  I'm not aware of any projects using an underscore.  We usually use a - to separate the basename from the application name.  E.g. blendinteractive-drupal
  • Sorry, wrote underscore, meant dash. I'll edit appropriately.

Answer

This is one of those "standards" that kind of just evolved, so I don't think it's entirely consistent. I think the idea of including the CMS / App name at the end of the project name is to give some information about expectations for the project merely by knowing it's name. I suppose if a version of a CMS were so different from it's previous version, it might make sense to include the major version in its project name, but to my knowledge we're not actually doing that anywhere yet. (the case could be made for symfony-flex projects, maybe?).

Currently, these are the ad-hoc examples I'm aware of for CMS names:

  • example-sms
  • example-drupal
  • example-ez (ezpublish legacy and 5+ and ezplatform sites both use this right now... not sure if that's problematic)
  • example-symfony
  • example-static
  • example-c5 (the '5' is a part of the cms name, not the version)
  • example-lamp (generic green-field lamp app. These usually are not developed by us)
  • example-ee (expressionengine)
  • example-ektron
  • example-episerver
  • example-wp
  • example-express (expressjs)

I'm sure there are more out there. Like I said, it's not entirely consistent, AFAIK, but these ones are mostly regular across projects.

Based on all that, I'd say that currently, your name for a drupal project would be foo-drupal , no matter whether it was drupal 7, 8, or 9. That matches all the current drupal 7 and 8 projects (9 isn't released yet) that we have.

Feel free to propose a better standard in the best practices repo if you have one.