[Userland] [OpenIndiana Distribution - Feature #4070] (New) Update oi-userland versioning scheme

[illumos project]

Issue #4070 has been reported by Alexander Pyhalov.

----------------------------------------
Feature #4070: Update oi-userland versioning scheme
https://www.illumos.org/issues/4070

Author: Alexander Pyhalov
Status: New
Priority: Normal
Assignee: OI Userland
Category: oi-build
Target version: 
Difficulty: Medium
Tags: needs-triage


h2. 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
<pre>
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.
</pre>

h2. 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.

h2. 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 
# IPS_COMPONENT_VERSION change, regardless of BRANCHID and COMPONENT_SUBVERSION
# BRANCHID change, regardless of COMPONENT_SUBVERSION
# 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.

 


-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://www.illumos.org/my/account