Note: You can reply either by editing the page or by clicking the Comment button at the bottom of the page.

Please refer to Version Specification Guidelines (Sun Internal) for the following discussion.

Current proposal

• openInstaller Solaris Package versioning

VERSION=<openInstaller_version>,REV=<YYYY.MM.DD.hh.mm>
SUNW_PRODVERS=<openInstaller_version>

e.g.

VERSION=0.9.2,REV=2007.06.19.17.58
SUNW_PRODVERS=0.9.2

• openInstaller RPM versioning

VERSION=<openInstaller_version>
REVISION=<some_revision>

• openInstaller RPM naming

sunw-install-engine-core-<openInstaller_version>-<some_revision>
sunw-install-resources-<openInstaller_version>-<some_revision>

• Windows

TBD

Both openInstaller_version and some_revision are specified in build.properties.template by the developer and from there are propagated to the naming and fields automatically by the build mechanism. The property keys are

PLATFORM_VERSION

PLATFORM_RELEASE

The following files are affected.

pkgdefs/engine/rpm/engine.spec.tmpl
pkgdefs/engine/solaris/pkginfo.tmpl
resources/dependency/Engine.xml
test/com/sun/install/provider/dependency/data/Engine.xml
test/com/sun/install/provider/system/data/Engine.xml
tools/build.properties.template

Open issues

The issues with the above proposal are

1. We have already shipped existing packages with 1.0 though no customer has gone outside with it.
2. Our current customers might not like the change.
3. Question: Is our customer still carrying the Engine.xml?
4. Though full control is provided by inclusion in

   build.properties.template

   , the policy on bumping

   VERSION

   and

   REVISION

   for RPM is unclear. What is an event that should cause increasing these numbers? How do nightly build versions fit into this?
5. The above does not address Windows yet.

James Falkner's Comments

Responses to open issues:

1. I doubt anyone would care if we change these versions as you say no one has shipped yet.

2. See #1

3. Yes. They will need to re-sync.

4. The policy should be governed by existing guidelines that other projects like Java ES follow. For example, for major.minor.micro:

Major change: should introduce significant functionality. Lifetime is long. Upgrade support is not required (though transition plan should be available). Hardware, file formats, interfaces go away or are new.

Minor change: signals that a software release contains either new, non-interfering features and architectural changes, or bug fixes. Each minor release must contain all the changes introduced in previous minor releases against the same major release. Interfaces may only be obsoleted by a minor release after a suitable warning and phase-out period. Minor releases should occur at regular, predictable intervals.

Micro: Are scheduled as necessary to introduce bug fixes are support new platforms. Each micro release must contain all changes introduced since the last minor release, as well as all patches made available since the last minor release. Interfaces must not be obsoleted by a micro release.

Note that this version does not necessarily correspond with the "marketing version".

It would be much easier to manage if marketing version was the same as version. - ManpreetSingh

Also, the RPM release field should contain two parts:

a.b

where

a=build identifier, and
b="update" level

Is this part of this proposal?

Yes

<some_revision>

5. Windows. There is currently no version inside of the .zip files used to transfer files to disk during windows install. The only place versions are stored are in the dependency descriptors. And this is the version recorded in SIMS. So this proposal should "just work" as we are not attempting to interact with the MSI system.