# Revision history [back]

Your ROS packages should belong to one or more stacks, because a stack is released and installed as a unit. Each stack contains one or more packages, the build dependency units.

When creating a new package, choose the name carefully:

• Package names are global to the entire ROS ecosystem.
• They are messy to change later.

Try to use names that make sense to others who may wish to use your code.

Each package can be built separately, so pay attention to dependencies. The package dependency graph must be acyclic, i.e. no package may depend on another that directly or indirectly depends on it.

• The overhead of a ROS package is not large. Define separate packages wherever they make sense.
• Avoid combining nodes that pull in mutually unneeded dependencies.
• To eliminate unnecessary build overhead, avoid combining nodes that are often used separately.
• If a code with similar dependencies is generally used together, consider combining it into a single package.
• If some nodes have common dependencies on shared code that you do not wish to export publicly, they can be combined internally within a single package.
• If the shared code should be exported, consider making it a separate package that the others depend on. (This is reasonable, but not required. A single package can export libraries and headers as well as nodes.)
• Consider combining message definitions in one or more separate packages. That usually simplifies the dependencies among packages, with nodes depending on the messages, and not so much on each other.

Your ROS packages should belong to one or more stacks, because a stack is released and installed as a unit. Each stack contains one or more packages, the build dependency units.

When creating a new package, choose the name carefully:

• Package names are global to the entire ROS ecosystem.
• They are messy to change later.

Try to use pick names that make sense to others who may wish to use your code.

Each package can be built separately, so pay attention to dependencies. The package dependency graph must be acyclic, i.e. no package may depend on another that directly or indirectly depends on it.

• The overhead of a ROS package is not large. Define separate packages wherever they make sense.
• Avoid combining nodes that pull in mutually unneeded dependencies.
• To eliminate unnecessary build overhead, avoid combining nodes that are often used separately.
• If a code programs with similar dependencies is are generally used together, consider combining it them into a single package.
• If some nodes have common dependencies on shared code that you do not wish to export publicly, they can be combined internally within a single package.
• If the shared code should be exported, consider making it a separate package that the others depend on. (This is reasonable, but not required. A single package can export libraries and headers as well as nodes.)
• Consider combining message definitions in one or more separate packages. That usually simplifies the dependencies among packages, with nodes depending on the messages, and not so much on each other.

Your ROS packages should belong to one or more stacks, because a stack is released and installed as a unit. Each stack contains one or more packages, the build dependency units.

When creating a new package, choose the name carefully:

• Package names are global to the entire ROS ecosystem.
• They are messy to change later.

• Try to pick names that will make sense to others who may wish to use your code.

• Each package can be built separately, so pay attention to dependencies. The package dependency graph must be acyclic, i.e. no package may depend on another that directly or indirectly depends on it.

• The overhead of a ROS package is not large. Define separate packages wherever they make sense.
• Avoid combining nodes that pull in mutually unneeded dependencies.
• To eliminate unnecessary build overhead, avoid combining nodes that are often used separately.
• If programs with similar dependencies are generally used together, consider combining them into a single package.
• If some nodes have common dependencies on shared code that you do not wish to export publicly, they can be combined internally within a single package.
• If the shared code should be exported, consider making it a separate package that the others depend on. (This is reasonable, but not required. A single package can export libraries and headers as well as nodes.)
• Consider combining message definitions in one or more separate packages. That usually simplifies the dependencies among packages, with nodes depending on the messages, and not so much on each other.

Your ROS packages should belong to one or more stacks, because a stack is released and installed as a unit. Each stack contains one or more packages, the build dependency units.

When creating a new package, choose the name carefully:

• Package names are global to the entire ROS ecosystem.
• They are messy to change later.
• Try to pick names that will make sense to others who may wish to use your code.
• Package names should start with a letter, and contain only letters, numbers and '_' characters. Lower case is preferred. Feel free to browse the current list for inspiriation.

Each package can be built separately, so pay attention to dependencies. The package dependency graph must be acyclic, i.e. no package may depend on another that directly or indirectly depends on it.

• The overhead of a ROS package is not large. Define separate packages wherever they make sense.
• Avoid combining nodes that pull in mutually unneeded dependencies.
• To eliminate unnecessary build overhead, avoid combining nodes that are often used separately.
• If programs with similar dependencies are generally used together, consider combining them into a single package.
• If some nodes have common dependencies on shared code that you do not wish to export publicly, they can be combined internally within a single package.
• If the shared code should be exported, consider making it a separate package that the others depend on. (This is reasonable, but not required. A single package can export libraries and headers as well as nodes.)
• Consider combining message definitions in one or more separate packages. That usually simplifies the dependencies among packages, with nodes depending on the messages, and not so much on each other.

Your ROS packages should belong to one or more stacks, because a stack is released and installed as a unit. repositories. Each stack repository contains one or more packages, the build dependency units.

When creating a new package, choose the name carefully:

• Package names are global to the entire ROS ecosystem.
• They are messy to change later.
• Try to pick names that will make sense to others who may wish to use your code.
• Package names should start with a letter, and contain only letters, numbers and '_' characters. Lower case is preferred. Feel free to browse the current list for inspiriation.

Each package can be built separately, so pay attention to dependencies. The package dependency graph must be acyclic, i.e. no package may depend on another that directly or indirectly depends on it.

• The overhead of a ROS package is not large. Define separate packages wherever they make sense.
• Avoid combining nodes that pull in mutually unneeded dependencies.
• To eliminate unnecessary build overhead, avoid combining nodes that are often used separately.
• If programs with similar dependencies are generally used together, consider combining them into a single package.
• If some nodes have common dependencies on shared code that you do not wish to export publicly, they can be combined internally within a single package.
• If the shared code should be exported, consider making it a separate package that the others depend on. (This is reasonable, but not required. A single package can export libraries and headers as well as nodes.)
• Consider combining message definitions in one or more separate packages. That usually simplifies the dependencies among packages, with nodes depending on the messages, and not so much on each other.