On Thu, Feb 22, 2018, Bertrand Garrigues wrote: > The other thing is that you probably want to have official release of > macro packages independantly from releases of the core system. If there > is real need for that then we could make some stable branches and > intermediate releases, following this flow: > > - Full version is released, e.g. 1.22.4. > > - A little bit later a macro package maintainer wants to make a release > that has no dependencies on the core system, but there were some > non-trivial changes since 1.22.4 and we are not ready to make a full > 1.22.5 release. In order to avoid regressions we make a stable branch > from tag v1.22.4 and the macro package maintainer commits on it, and > creates a 1.22.4-1 release.
My solution to this issue long ago was to develop and release mom independently of groff. It made sense because mom is, as someone opined, her own beast. om.tmac-u in contrib/mom is always in sync with the latest independent mom release, which uses her own versioning system. Users needing a more recent mom can get it far more easily by downloading it from her web page than by pulling groff from the repo. This method has proven effective for nearly a decade and a half, so I don't see the need for creating a split-off "macro package release." If there were a number of macrosets in active development it might make sense, but there aren't. The classical macros rarely get touched. As for putting a burden on the reigning "brain surgeon" to muck about with unfamiliar macro code, I have observed that that rarely happens. Generally, macro authors or list members familiar with the code delegate themselves to the task. -- Peter Schaffter http://www.schaffter.ca
