In the new world of second generation packaging (2GP) capabilities such as Unlocked Packages mean the technical aspects of packaging are no longer a concern only for ISV developers but are now equally applicable to enterprise development. The Salesforce Developer Experience (SFDX) developer guide documentation provides a great reference for those getting started with packaging which covers all the main implementation considerations. One area that isn’t covered is the management of package versions in practice; I call this a package version scheme, an example of which is included below.

Package Version Scheme:

Convention [Major.Minor.Patch.Build]

Pre-release development; 0.1.0-x .. 0.2.9-x
• First-release; 1.0.0-1
• Post-initial-release bugfixes; 1.0.1-x .. 1.0.3-x
  (Patch number must increment per package version release)
• Post-initial-release internal builds; 1.1.0-x
  (Only the Build number must increment per package version release)

Next-release (minor enhancement); 1.1.0-x (Release with the final build number)
• Post-minor-release bugfixes; 1.1.1-x .. 1.1.3-x
  (Patch number must increment per package version release)
• Post-minor-release internal builds; 1.2.0-x
  (Only the Build number must increment per package version release)

Next-release (major enhancements); 2.0.0-1
• Post-major-release bugfixes; 2.0.1-x .. 2.0.3-x
  (Patch number must increment per release)
• Post-major-release internal builds; 2.1.0-x
  (Only the Build number must increment per release)

Additional references:
https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_manpkgs_package_versions.htm
https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_intro.htm