Talk:Package versioning policy
Add topicHow about describing the semantics of versions in the following way?
1. If none of the module interfaces of your package have changed, the A.B.C prefix can remain the same.
2. If a user of the package only used qualified imports and/or imports a specified list of functions would imply that they could use your new package version, then the A.B prefix can remain the same.
3. Otherwise, the A.B prefix must be incremented.
Is this equivalent to the versioning policy?
--Roconnor 20:28, 29 August 2009 (UTC)
A special case that is not discussed is change of fixity. I presume fixity changes should require bumping the major version?
--Bjorn 15:01, 8 April 2011 (UTC)
The policy only considers changes to the API, which is only one side of the packages surface, changes in dependencies aren't taken into account at all.
I've often thought that the following statement should hold:
- If I have a set of packages where all dependencies are satisfied, then it should be possible to update any of those packages to a new minor version (e.g. from Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle X.Y.Z} to Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle X.Y.Z+1} ) without any other updates.
As a packager for a Linux distro such a goal would be very welcome. I believe the following rules would achieve that:
- Use dependencies that are insensitive to changes in minor versions as far as possible.
- Increase the major version if the lower bound of a dependency is adjusted up to a new major version.
-- MagnusTherning 19:08, 5 January 2012 (UTC)