[oi-dev] OpenIndiana /hipster build number

[Andrzej Szeszo]

I propose a new scheme similar to the following:

Current version strings:

pkg://openindiana.org/SUNWcs@0.5.11,5.11-0.151.1.8.1
pkg://openindiana.org/shell/bash@4.2.45,5.11-0.151.1.8.1
pkg://openindiana.org/package/pkg@0.5.11,5.11-0.151.1.8.1

Proposed new version strings:

pkg://openindiana.org/SUNWcs@0.5.11,5.11-0.2014.0.0.14302.2476
pkg://openindiana.org/shell/bash@4.2.45,5.11-0.2014.0.0.0.2476
pkg://openindiana.org/package/pkg@0.5.11,5.11-0.2014.0.0.5055.2476

The numbers would have the following meaning:

PKGVERS_BRANCH =
0.$(IPSREPO_YEAR).$(IPSREPO_NUM).$(IPSREPO_SUBNUM).$(PKGREV_COMPONENT).$(USERLAND_ID)
PKGVERS = $(PKGVERS_COMPONENT),$(PKGVERS_BUILTON)-$(PKGVERS_BRANCH)

Currently, /hipster IPS repository is only growing, there is no way to
obsolete packages in it, updates and all operations are becoming
slower and slower. I propose importing latest installable packages
from /hispter into /hipster-2014.0 and continuing work in a new
smaller repo. If it becomes too big, we could switch over to
/hipster-2014.1, etc.

I don't think "$(PKGVERS_COMPONENT),$(PKGVERS_BUILTON)-" part of the
proposer version string needs much explanation. For illumos-gate or
pkg5 packages it will always be 0.5.11,5.11-, for other packages it
will be package-version,5.11- (4.2.45,5.11- in case of bash).

The -0.2014.0 part would say which pkg.openindiana.org/hipster-20xx.x
IPS repo package is coming from, for example:

-0.2014.0 = http://pkg.openindiana.org/hipster-2014.0
-0.2014.1 = http://pkg.openindiana.org/hipster-2014.1

IPSREPO_SUBNUM we could bump when there is a "flag day", or when
multiple packages have to be rebuilt for some reason and updated as
the same time.

PKGREV_COMPONENT could be used to specify revision on the component in
the oi-userland, or in case of illumos-gate or pkg5 could be set to
git commit number of illumos-gate or pkg-gate.

USERLAND_ID could be set to oi-userland git commit number that was
used at the time of building the package.

Wondering what others think about the versioning scheme.

Cheers,

Andrzej



On 4 January 2014 05:46, Gordon Ross <gordon.w.ross at gmail.com> wrote:
> Yes, that might be useful, but you'll probably need to get discussion
> going among the various illumos players about what sort of version
> labeling scheme would work for them.
>
> On Thu, Nov 21, 2013 at 1:10 AM, Alexander Pyhalov <alp at rsu.ru> wrote:
>> Hello, people.
>> Let's do something about package versions. It's  really awesome to have the
>> newest illumos-gate version. But it breaks existing installations. In
>> current scheme packages are always compiled against latest illumos and we
>> have no way to distinguish between package versions.
>>
>> I see several ways to deal with this problem.
>> 1) Building  illumos-gate only once a week/two weeks/etc, bump ONNV_BUILDNUM
>> (and perhaps BRANCHID at the same time) in  jenkins or in cron job
>> (151.1.8.1.N).
>>
>> 2) We can generate incremental series of ONNV_BUILDNUM automatically and in
>> consistent way. For example,
>> changing
>>
>> echo export ONNV_BUILDNUM=$(ONNV_BUILDNUM)
>>
>> to
>>
>> echo export ONNV_BUILDNUM=$(ONNV_BUILDNUM).$$(git log --format=%H |wc -l|tr
>> -d ' '))
>>
>> in components/illumos/illumos-gate/Makefile
>>
>> will generate consistent (but perhaps, not human-friendly) series of
>> numbers.
>>
>> Any other suggestions?
>> --
>> Best regards,
>> Alexander Pyhalov,
>> system administrator of Computer Center of Southern Federal University
>>
>> _______________________________________________
>> oi-dev mailing list
>> oi-dev at openindiana.org
>> http://openindiana.org/mailman/listinfo/oi-dev
>
>
>
> --
> Gordon Ross <gwr at nexenta.com>
> Nexenta Systems, Inc.  www.nexenta.com
> Enterprise class storage for everyone
>
> _______________________________________________
> oi-dev mailing list
> oi-dev at openindiana.org
> http://openindiana.org/mailman/listinfo/oi-dev