I propose a new scheme similar to the following: Current version strings:
pkg://openindiana.org/[email protected],5.11-0.151.1.8.1 pkg://openindiana.org/shell/[email protected],5.11-0.151.1.8.1 pkg://openindiana.org/package/[email protected],5.11-0.151.1.8.1 Proposed new version strings: pkg://openindiana.org/[email protected],5.11-0.2014.0.0.14302.2476 pkg://openindiana.org/shell/[email protected],5.11-0.2014.0.0.0.2476 pkg://openindiana.org/package/[email protected],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 <[email protected]> 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 <[email protected]> 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 >> [email protected] >> http://openindiana.org/mailman/listinfo/oi-dev > > > > -- > Gordon Ross <[email protected]> > Nexenta Systems, Inc. www.nexenta.com > Enterprise class storage for everyone > > _______________________________________________ > oi-dev mailing list > [email protected] > http://openindiana.org/mailman/listinfo/oi-dev _______________________________________________ oi-dev mailing list [email protected] http://openindiana.org/mailman/listinfo/oi-dev
