On 2016-01-21 11:39 PM, Henry So Jr. wrote:
If a TeX-only change happened to break the TeX API, that would
require the major number be increased, or are you implying that we
disallow such changes on the TeX Live branch?
We would have to. Bumping the major version number would run afoul of
our version consistency checks which require that the binary have the
same major version number as the TeX files.
Right now, new feature requests require C changes more than 80% of
the time. This means that we potentially have to support two stable
branches and two unstable branches. This might be too much for a
small group such as ours.
It might, but if the break down of the feature requests is as you
describe, then the TeXLive branches would be fairly quiet and only
TeX-only features could be added on those branches. Further all
changes made on the TeXLive branch would be ported over to the main
branches, so the real maintenance would be on those branches.
An alternative is to cut a TeX Live release, maintained on a branch
to support ONLY bug fixes that are not C-related, a stable branch
(master), and an unstable branch (develop). This way, we only need
to support three branches. If we do this, by definition, only the
patch number would change on TeX Live releases. If there is a C
change (even only a bug fix) against the TeX Live version, that would
necessitate bumping the minor number (whichs compromises semantic
versioning slightly), but we could otherwise continue versioning as
we are.
That's certainly a good alternative. I think being able to push at
least bug-fixes to CTAN is a good idea.
On 2016-01-22 1:29 AM, Élie Roux wrote:
That's a good point, but I really don't think it's necessary. The way
it's usually done is the following: develop as much as you want
between two TeXLive builds (once a year), changing version, etc. and
make a good and stable release for the TeXLive build, so that people
who don't update outside TeXLive have a good enough version. That's
basically the workflow of LuaTeX, XeTeX and all other softwares. So I
was thinking about doing the same with gregorio: release a good,
stable 4.1 for TeXLive 2016, then continue the way we're used to,
and make a good, stable 4.x or 5.x (or 6.x!) for TeXLive 2017, etc.
I'm one of those people that runs tlmgr fairly often (through the TeX
Live Utility for Mac) and thus get regular updates of many packages
during the course of the year, including LuaTeX. Right now there's an
new file luatex-def waiting to be installed and looking in the backups I
see updates to several luatex packages from October and December. This
might be a sort of "early adopter" status for these packages, but they
are getting updated between the big releases.
These updates are being retrieved from CTAN (or one of its mirrors) and
it's them that I am thinking about. We don't have to push updates to
CTAN during the course of a year, but if we do, they cannot be updates
which rely on change to the C code (since the binaries are not rebuilt
during this update process). That also necessitates the major version
of updates pushed to CTAN not change (otherwise our version consistency
checks will fail).
All that said, I am not wedded to any particular model. We have plenty
of time to figure this out as whatever we decide won't be implemented
until after 4.1 is released.
✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝
Br. Samuel, OSB
St. Anselm’s Abbey
Washington, DC
(R. Padraic Springuel)
PAX ☧ ΧΡΙΣΤΟΣ
_______________________________________________
Gregorio-devel mailing list
[email protected]
https://mail.gna.org/listinfo/gregorio-devel
