Project

General

Profile

Feature #4070

Update oi-userland versioning scheme

Added by Alexander Pyhalov about 6 years ago. Updated over 3 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
OI-Userland
Target version:
-
Start date:
2013-08-22
Due date:
% Done:

50%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage

Description

Current state

Currently, we have the following versioning scheme in oi-userland. Package version (VERSION,Build Release-Branch:Timestamp)
usually is determined as ($IPS_COMPONENT_VERSION),$(BUILD_VERSION), where $BUILD_VERSION is determined as $(PKG_SOLARIS_VERSION)-$(BRANCHID) in make-rules/ips-buildinfo.mk and Timestamp is automatically updated. Now we have BRANCHID set to 0.151.1.8.1 .

Solaris 11 has the following versioning scheme for BRANCHID: http://docs.oracle.com/cd/E26502_01/html/E21383/glyvm.html#scrolltoc

0.175.1.0.0.2.1
Branch version. Oracle Solaris packages show the following information in the branch version portion of the version string of a package FMRI:

0.175
Major release number. The major or marketing development release build number. In this example, 0.175 indicates Oracle Solaris 11.

1
Update release number. The update release number for this Oracle Solaris release. 
The update value is 0 for the first customer shipment of an Oracle Solaris release, 
1 for the first update of that release, 2 for the second update of that release, and so forth.
 In this example, 1 indicates Oracle Solaris 11.1.

0
SRU number. The Support Repository Update (SRU) number for this update release.
SRUs include only bug fixes; they do not include new features. 
The Oracle Support Repository is available only to systems under a support contract.

0
Reserved. This field is not currently used for Oracle Solaris packages.

2
SRU build number. The build number of the SRU, or the respin number for the major release.

1
Nightly build number. The build number for the individual nightly builds.

The problems

I see two problems with current versioning scheme.
  • Firstly, we don't have a way to automatically trigger package clean and rebuild if Makefile is not changed during package update (for example, when maintainer change patch to a packge). This currently is worked around by manual gmake clean on server or insignificant Makefile modification (for example, adding some spaces to Makefile triggers clean-publish events).
  • Second (and more serious) trouble is that we don't have a way of automatically downgrading package versions. And in /hipster when we update packages we sometimes can't predict what other packages and in what way this update affects. Recent examples - zlib update breaking Firefox, some vagueness with sqlite update.

Proposed solution

I think that following can work.
  • Adding to oi-userland build system additional COMPONENT_SUBVERSION variable (0 by default) which indicates local change of the package and must be changed with every local package modification. It is resetted to 0 when upstream component version updates. BUILD_VERSION is set to $(PKG_SOALRIS_VERSION)-$(BRANCHID).$(COMPONENT_SUBVERSION). So that new package versions will look like 0.151.1.8.1.$(COMPONENT_SUBVERSION). We should require that maintainer changes COMPONENT_SUBVERSION on every change in the package. In this way the first problem is solved - every time the package is changed, Makefile is affected and clean rebuild is triggered. Also we have a way for end user to determine if package was just rebuilt or significantly changed. Also note, that in this package versioning scheme update can be triggered by
    1. IPS_COMPONENT_VERSION change, regardless of BRANCHID and COMPONENT_SUBVERSION
    2. BRANCHID change, regardless of COMPONENT_SUBVERSION
    3. COMPONENT_SUBVERSION change
  • Adding to oi-userland build system constant FICTIVE_VERSION. For all packages which should be downgraded set IPS_COMPONENT_VERSION to FICTIVE_VERSION and change only COMPONENT_SUBVERSION incrementally. We can reset COMPONENT_SUBVERSION to 0 when CONSTANT_BUILD_VERSION is incremented. Real package version should be set as HUMAN_VERSION and determine pkg.human-version IPS property. FICTIVE_VERSION should be an arbitrary high number (100, 511, 1000, as you like) so that it is more than any sane real package version. So, when we set IPS_COMPONENT_VERSION to FICTIVE_VERSION we can trigger IPS package update even when we really downgrade the package.

History

#1

Updated by Aurélien Larcher over 3 years ago

Is it not what you implemented with COMPONENT_REVISION ? Can this be closed ?

#2

Updated by Alexander Pyhalov over 3 years ago

  • Category changed from 35 to OI-Userland
  • Status changed from New to Closed
  • % Done changed from 0 to 50

I think this one can be closed. Andrzej has implemented good scheme. However, we haven't implemented FICTIVE_VERSION. But it has its own advantages, as IPS always shows real package version. So I'm reluctant to doing this.

Also available in: Atom PDF