Would be nice to see some detailed explanation about cases when developer must use extended version fields, with examples: i.e. open some "feature" issue and explain your suggestions there.
Alexander On 21.08.2013, at 23:22, Alexander Pyhalov <[email protected]> wrote: > Alexander Eremin писал 21.08.2013 21:25: >> IPS pkg version has enough fields (four) for this. May be for some >> cases just use third field (branch version), which provides >> vendor-specific info, can contain build number or any other info? > > Yes, I don't suggest change IPS, just userland makefiles which generate > version numbers - it still can be encoded in first and third field. I think > we just need some agreements on modified versioning scheme and perhaps some > tools to enforce this scheme. For exampel IPS_COMPONENT_SUBVERSION can be the > last number in third field. > >> On 21.08.2013, at 21:12, Alexander Pyhalov <[email protected]> wrote: >> Hello. >> I'd like to suggest the following topic for discussion - package versions. >> We have several problems in /hipster: >> a) to trigger package update it is necessary to touch Makefile >> b) we need an indication that package wasn't just rebuilt, but was changed >> c) we don't have a rollback mechanism for package updates. >> There are several possible actions: >> 1) add IPS_COMPONENT_SUBVERSION variable which indicates local change of >> the package and must be changed with every package modification, so that >> package number looks like >> $(IPS_COMPONENT_VERSION).$(IPS_COMPONENT_SUBVERSION),$(BUILD_VERSION) or >> similar; >> 2) for packages having spoiled package versions introduce var like >> IPS_FICTIVE_VERSION with arbitrary high values (100, 1000, etc), set >> IPS_COMPONENT_VERSION to it, IPS_HUMAN_VERSION to real version and use >> incremented IPS_COMPONENT_SUBVERSION. > > --- > System Administrator of Southern Federal University Computer Center > > > > _______________________________________________ > 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
