How does the composer behave when updating packages?

  

If I rename the directory lib/ to src/ . The right thing would be to make the package available as v1.0.1 or v1.1.0 ?

It can be v1.0.1 following the normal sequence of your package and for being a fix, do not forget to update this new version on your github or local of package storage. When you have a big change, the recommended version would be v2.0.0 and minor corrections continue in numbering with addition of 1 and if it is adding new functionality that nothing compromises the versions would be v1.1.0 .

Summarizing in your case would be v1.0.1

  

In addition, when renaming this way, would it be detrimental to update on the clients that already have the package?

Whoever downloads the new version will have no problem, because composer gives a command to reload the packages (if he wants to download the old one, the folder will still be lib/ ). It is worth remembering that your package will have two versions with a simple change of storage folder (correction), really, src/ would be a standard adopted by several packages.

When new versions are released, changes are applied at installation time.

On the github text:

English

  

Tagging suggestions It's common practice to prefix your version names   with the letter v. Some good tag names might be v1.0 or v2.3.4.

     

If the tag is not meant for production use, add the pre-release version   after the version name. Some good pre-release versions might be   v0.2-alpha or v5.9-beta.3.

Translation:

  

Marking Tips It is common practice to prefix your version names   with the letter v. Some good tag names can be v1.0 or v2.3.4.

     

If the tag is not used for production, add a version of   pre-release after the version name. Some good versions of   pre-release can be v0.2-alpha or v5.9-beta.3.

That is,

If it is a release ( post )

v1.0.2 //último lançamento geralmente usado para correções
v1.0.1
v1.0.0

If it is production ( production )

v0.0.2-alpha //última produção
v0.0.1-alpha

In addition to this basic explanation, there is a text in Semantic Versioning 2.0.0 , which can clarify your doubts.

Example:

v1.2.0 //isso é um mero exemplo.

  

Number 1 is the MAJOR (changes of its API that cause incompatibility with the old ones)

     

Number 2 is MINOR (adding features that are compatible with the current version)

     

The number 0 is the PATCH (fixes, bugs )

English

  

MAJOR version when you make incompatible API changes,

     

MINOR version when you add functionality in a backwards-compatible manner, and

     

PATCH version when you make backwards-compatible bug fixes.

Translation:

  

MAJOR when you make incompatible changes from API ,

     

% version_company when you add functionality in a backwards-compatible way,

     

MINOR when you make bug fixes backwards compatible.

References:

• Dependency Manager for PHP
• Semantic Versioning 2.0.0
• Creating Releases
• Working with Tags