1. Igor Kozhukhov(dilos)
  2. site


Clone wiki

site / DilOS_version_scheme

DilOS version scheme

I’d like to propose version scheme:

{MAJOR} - major version. will be changed as major release. Maybe will be changes at once in year.
{MINOR} - minor version. will be changed with new release. Depend on scheduler of releases.
{BUILD} - build number. will be changed between uploads to dilos-unstable.
{PATCH} - patch number. will be changed with every components updates. Components will be stored at du-unstable (dilos-userland) and dg-unstable (dilos-illumos-gate) for testing.

How to get new components from 'du-unstable' and 'dg-unstable' repos?
It is easy: need update /etc/apt/sources.list by new lines:

deb http://apt.dilos.org/dilos du-unstable main contrib non-free
deb http://apt.dilos.org/dilos dg-unstable main contrib non-free

IMPORTANT: these repos should have UNSTABLE/UNTESTED components.
You have riski to update your system from these repos. These repos will contain packages after builds on CI(jenkens Continuous Integration) system.

Will be better to use repo:

deb http://apt.dilos.org/dilos dilos-testing main contrib non-free

Example of version:
We have current tag version on dilos-userland: it is
We have your own fixed component.
We can see on 'component.ver' file version:
For new update we have to change version to '', because primary version of userland is ''.
If we have another fix for this component we have to increase latest number to '' and etc.
We have some weekly - 2-3 weekly updates and we want to push changes from du-unstable to dilos-unstable. We will mark new tag: '', push all components from du-unstable -> dilos-unstable. After this operation we have to use new version for fixed components: '1.2.8.x' and etc.

This scheme be able to identify: how much components have been changed between tags, between releases, how often some packages have been changed.