On Thursday, 21 January 2016 at 05:30:19 pm -0500, Br. Samuel Springuel wrote: > Something that just occurred to me. > > 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. 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. > > As it stands, our own version checking would dictate that on the TeXLive > branch, the major version cannot change during the course of the year, > but the minor or patch version could. I thus propose the following:
This, however, breaks semantic versioning. 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? > TeXLive branch releases have a odd minor version number (4.1.0, 4.3.0, > etc.). Self-install branch releases have even version numbers (4.0.0, > 4.2.0, etc.). These branch numbers would advance independently of each > other during the course of the year, except when it comes time to > prepare for the building of TeXLive binaries. At that point we advance > the numbers so that the first self-install release after the TeXLive > binaries are built (thus freezing C development on the TeXLive branch > for another year) would be 1 higher than the TeXLive release for that year. > > Thoughts? Other ideas as to how to handle this impending development split? 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. 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. I'm not necessarily proposing this; just putting another idea on the table. Henry _______________________________________________ Gregorio-devel mailing list [email protected] https://mail.gna.org/listinfo/gregorio-devel
