Unlike typical "semantic versioning", Fedora defines the following meaning to each of the three positions of a version number in a release such as: Fedora-4.1.2

4 (in '4'.1.2) - product version (i.e. Fedora4, this number will not change unless there is a significant architectural shift or project milestone in the Fedora application).
1 (in 4.'1'.2) - major version (this number increments every time there is either a non-backwards compatible API change or an equally significant project milestone)
2 (in 4.1.'2') - combined minor version and bug-fix version (this number is incremented in the course of regular, frequent, maintenance releases)

  • No labels

6 Comments

  1. A. Soroka

    "backwards compatible API change" is a term that will be fully-defined only when the Fedora API itself is fully-defined, which work is proceeding at a glacial pace.

  2. Justin Coyne

    Why not adopt a 4 part scheme? Then you'd be able to differentiate patch version from minor version.  If there is a security fix, I may want to apply that fix without adopting new features that may introduce new bugs.

  3. Ralf Claussnitzer

    Is this scheme compatible with Maven versioning? http://books.sonatype.com/mvnref-book/reference/pom-relationships-sect-pom-syntax.html

    Semantic versioning needs to work with the main build system, especially that if the goal is to have stable APIs and not just marketable product releases. Maybe it's better to put the "fixed major number" into artifact names? This is already the case with fcrepo3 and fcrepo4 repository naming...

    1. Andrew Woods

      You make a good point, Ralf Claussnitzer. It would appear that a 4-position versioning scheme would cause trouble for Maven:

      At this point, moving the product number into the artifact name would likely be confusing for the actual version numbers. Possibly using Maven's qualifiers for patch releases would work: 4.3.0-patch1

       

  4. Unknown User (acoburn)

    From the "Understanding Maven Version Numbers" page (linked above), I would point out this line:

    All versions with a qualifier are older than the same version without a qualifier (release version).

    That would mean, for instance, that a 4.3.0 release will always be "newer" than 4.3.0-patchX, so using qualifiers for this wouldn't work.

    1. Andrew Woods

      That would seem to push us in the direction of either standard semantic versioning (casting any special significance to the major version number "4" to the wind), or maintaining our current approach of collapsing minor and bugfix versions. Are you seeing other options?

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.