How does Composer behave when upgrading packages?

Asked

Viewed 27 times

1

I have the version ^1.0.0 of a package. As well as autoload prefix "\\Empresa\\Pacote": "lib/".

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

Also, by renaming in this way, it would hamper upgrading to customers who already own the package?

commiserate

1 answer

2


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

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

In short in your case would v1.0.1

Also, by renaming in this way, it would hamper upgrading to customers who already own the package?

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

When new versions are launched changes are applied at the time of installation.

On the website of has a 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 isn’t Meant for Production use, add a pre-release version after the version name. Some good pre-release versions Might be v0.2-alpha or v5.9-beta.3.

Translation:

Markup suggestions 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-launch may be v0.2-alpha or v5.9-beta.3.

That is to say,

If it is a release (launching)

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

If it is production (producing)

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, that can clarify your doubts.

Example:

v1.2.0 //isso é um mero exemplo.

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

The number 2 is MINOR (addition of features that are compatible with the current version)

The number 0 is PATCH (corrections, 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 to API,

MINOR version when you add functionality in a manner compatible with previous versions and

PATCH when you make bug fixes compatible with previous versions.

References:

Browser other questions tagged commiserate

You are not signed in. Login or sign up in order to post.