B2B package naming

This tip is from GEAR but is worth repeating here as I’ve seen instances where this practice isn’t followed and it can cause some heartburn.

Use a meaningful package name. Names that reflect the business process (preferred) or a specific system work well.

Each package should have only one top-level folder. It should be named exactly the same as the package.

As you know, packages are a config management construct. Package names are not used in any form within the services themselves. Making the package name and the top-level folder name the same makes it MUCH easier to find a specific service that you may be looking for.

This also helps to avoid namespace conflicts, since no two packages can have the same name.

Anyone have an example of when this guideline should NOT be followed?

We follow this convention, with a twist that has caused a problem. We originally tried indicating versions in the package name, so that we might name the package “Pizza100”, and the top level folder “Pizza”.

We did this knowing the package name wasn’t used in the namespace. But in 4.0.1, the package name is referenced in package dependencies, so that you have to modify these when you change the package name.

So now we are planning on using the built-in versioning that seems to have been added after 3.6.