Re: [groff] Macro in separate packages

[Peter Schaffter]

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