I'd like to start a discussion not so much about git and branches and stuff, but more about what our release pattern will be and how that will be managed. It's inspired in part by some worries Pavel expressed:
> i have been thinking about the proposed changes last couple of days > and from many small things the main issue occuring to me again and > again is that the new model of each 6 months release is going to be > harmful for the overall stability of the stable lyx releases in general. > > 6 months mean 2 corrective releases (in current counting) and i think > that if we end with 2.0.2/3 there is not enough time to even catch > problematic bugs so the final 2.0.x release will be steep drop in > quality compared to the previous releases. > > to my taste such price for pushing new features out quickly is inadequate. > Speaking as branch maintainer, and also as a LyX user, I too worry about this. It's important that we have a culture that promotes LyX's stability. So what I'd like to suggest is that we NOT change our release schedule. We should plan to release 2.1 in about 18 months. However, if we move to the "features in branch model" that Vincent and Abdel have been proposing, then I think that would make it MUCH easier to merge new features into branch when we thought they were really ready and didn't touch too much other code. (This means that bug-fixing of such features ideally ought still to be done in that same branch, but that is more a workflow issue, and I'm trying not to talk so much about that.) Part of my reason for this proposal is that I don't think having intermediate "feature" releases would actually make very much difference. Some of the big 2.0 features could have been integrated into 1.6, had they been deemed sufficiently complete and tested, e.g., comparison and advanced F&R. And if you look at the list of new 2.0 features, you'll see that most of them involved format changes, either to the LyX file (XeTeX, Refstyle, Indices, etc), to layout files (XHTML), or to preferences (continuous spell-check), if not to more than one of these (required arguments). So I would propose to maintain two versions of BRANCH_2_0_X, much as the release maintainer, under the Vincent-Abdel proposal (as I understand it) would maintain two versions of trunk (the experimental one and one that is more stable). These would be: branch-20x/stable, which would be essentially the existing branch; and branch-20x/experimental, which would be where the new features went first, when they were deemed ready for branch. When they had received sufficient testing there---I at least would use that branch for daily work and would suggest others do the same---then they could be moved to stable and included in the next release. This would allow some new features, more than now, to be included in the 2.0.x series, without, it seems to me, reducing the stabilization period our current release cycle allows. And, as I said, I doubt that it would actually lead to fewer new features being included than would be included if we went with defined feature releases every six months. Comments? Richard
