Dear All,

>> Given that we're going to be targeting 4.1 for the TeXLive 2016
>> release cycle, we need to give some thought about how we are going
>> to differentiate version numbers for the TeXLive releases and the 
>> self-install releases.

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.

>> This is necessitated by the fact that TeXLive binaries are only
>> built 1/year so we cannot make any changes to the C code on the
>> TeXLive releases during the course of the year, but could push
>> changes to the TeX code to CTAN for people to using tlmgr and 
>> similar update solutions.

I think that would be a bad idea to push changes to CTAN between TeXLive
releases...

> 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.

Indeed

> 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.

I like this solution better yes, but I'm not sure it's necessary, people
who really want updates can just uninstall their TeXLive gregorio and
install one from our installers.

What do you think?

Thank you,
-- 
Elie

_______________________________________________
Gregorio-devel mailing list
[email protected]
https://mail.gna.org/listinfo/gregorio-devel

Répondre à