doc/branchid-change-instructions.md

   1 # BRANCHID change instructions
   2
   3 BRANCHID is set in [make-rules/ips-buildinfo.mk](../make-rules/ips-buildinfo.mk) as
   4
   5 ```
   6 BRANCHID ?= $(RELEASE_MAJOR).$(RELEASE_MINOR).$(UPDATENUM).$(COMPONENT_REVISION)
   7 ```
   8
   9 RELEASE_MAJOR is usually set to current year, RELEASE_MINOR and UPDATENUM are bumped when necessary and COMPONENT_REVISION is set by components individually to represent component modification.
  10
  11 BUILD_VERSION is set in the same file as
  12
  13 ```
  14 BUILD_VERSION ?=  $(PKG_SOLARIS_VERSION)-$(BRANCHID)
  15 ```
  16
  17 Published packages version is set to ``$(IPS_COMPONENT_VERSION),$(BUILD_VERSION)``, where ``IPS_COMPONENT_VERSION`` is set to ``COMPONENT_VERSION`` if not explicitly defined in component's Makefile.
  18
  19 Sometimes, on major packages updates, on changing repository, on releasing new snapshot we have to change BRANCHID.
  20
  21 The main issue during this process is to ensure that components, using auto-generated PLV, RUBYV and PYV manifests are republished after BRANCHID change.
  22
  23 This is necessary, because their publishing logic is broken in some way, and they can be published twice. On the first publish everything goes OK, but on the second only meta-package,
  24 dependent on individual packages versions,  is republished. As it includes dependency on $(IPS_COMPONENT_VERSION),$(BUILD_VERSION) subcomponents and BUILD_VERSION is changed,
  25 we receive non-installable package.
  26
  27 To find components, which should be republished, use
  28
  29 ```
  30 git ls-files '*VER.p5m'   | xargs -n 1 dirname
  31 ```
  32
  33 As of May 2019 these are the following components:
  34
  35 ```
  36 developer/mercurial
  37 developer/pkgtree
  38 perl/*, excluding perl interpreters
  39 python/*, excluding python interpreters
  40 sysutils/rdiff-backup
  41 ```