[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [groff] Macro in separate packages
From: |
Peter Schaffter |
Subject: |
Re: [groff] Macro in separate packages |
Date: |
Wed, 21 Feb 2018 21:52:15 -0500 |
User-agent: |
Mutt/1.5.24 (2015-08-30) |
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