Update oi-userland versioning scheme
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
- 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.
Updated by Alexander Pyhalov about 5 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.