| Line 19: | Line 19: | ||
{{admon/warning|Use of Epochs|The Epoch tag in RPM is to be used only as a last resort, and should be avoided whenever possible. However, it is sometimes necessary to use an Epoch to handle upstream versioning changes or to ease transition from third party repositories.}} | {{admon/warning|Use of Epochs|The Epoch tag in RPM is to be used only as a last resort, and should be avoided whenever possible. However, it is sometimes necessary to use an Epoch to handle upstream versioning changes or to ease transition from third party repositories.}} | ||
When successfull, all this extra workload and attention is '''lost work hours''' and away from more productive distribution work, '''causes extra package builds in build system''' (equals to loss of computing power, storage and electricity) even '''may cause problems for end users'''. Thus all of it should be avoided if possible. | |||
distribution work, causes extra package builds in build system and even may cause problems for end users. Thus all of it should be avoided if possible. | |||
== Problematic Cases == | == Problematic Cases == | ||
Revision as of 16:09, 12 January 2011
Upstream Versioning Recommendation (Draft)
This text tries to communicate to upstream projects about implications of different kind of software versioning schemes from downstream point of view.
While addressing the schemes that cause more workload and attention in downstream, it also gives a recommendation that should work for most of the projects and is harmless and straight forward in distribution packagers and end user's point of view.
Motivation
Some versioning schemes need extra attention while packaging them into distribution. If a package maintainer fails to do that, upcoming upstream releases might have versions that break automatic package upgrade path and then forces packager to use an Epoch tag, which is irrevocable decision and causes even more attention in future package updates.
The Epoch tag in RPM is to be used only as a last resort, and should be avoided whenever possible. However, it is sometimes necessary to use an Epoch to handle upstream versioning changes or to ease transition from third party repositories.
When successfull, all this extra workload and attention is lost work hours and away from more productive distribution work, causes extra package builds in build system (equals to loss of computing power, storage and electricity) even may cause problems for end users. Thus all of it should be avoided if possible.
Problematic Cases
While Packaging Guidelines describes these cases in great detail, here we outline an abstract of the issue. There are three cases when versions need extra attention:
- pre-release versions
- snapshot versions
- post-release versions
how the string parts in version may have to be moved into package Release Tag.
Optimal Schemes
Projects should avoid using non-numerical versions.
list examples with different major + minor combinations
list examples of projects which tackle different releases (pre-, snap-, post) without non-numeric parts