I did not follow the whole discussion, but I'd like to share a few thougts nevertheless. From a users point of view, it is important to have an understandable versioning and release scheme. IMHO the current numbering is very good: Easy to understand, and with some background at http://www.lyx.org/VersioningSystem. Four-digit numbers are overkill, and some interwoven scheme is too difficult IMHO.
Pavel Sanda wrote: > Julien Rioux wrote: > >>>> a) make new code available early > > 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. Yes. I would suggest two simple things to speed up the release cycle: 1) Develop in incremental steps and keep the development branch as usable as possible. 2) Close trunk for new features much earlier. This will lead to a much shorter alpha->release phase. >> I'm also glad that my only objection with the above list is c) develop >> new features in branches. I don't think it's necessary for most features, >> only for largish ones that are likely to take time and break the normal >> bug-free level in the main dev branch. > > my fear is also that while the extensive branch usage is superior from > the geeky point of view, its hindrance for people not so technically > skilled. do we want only geeks to be around? For casual contributors or curious users it should be possible to work without branches, as it is possible now. Another important point that was already mentioned by somebody, but can't be overestimated, are merge conflicts: No matter how good your VCS is, if you use branches extensively for parallel development, you will have merge conflicts that need manual resolving (or you need agreements such as "don't touch area xxx for the next month", but then the branch usage has no real advantage). Resolving merge conflicts is a boring task with high potential for mistakes, so it should be avoided if possible. In my experience the best way to avoid complex merge conflicts is to develop in small steps, and commit often to the main branch. This requires some disclipine, but overall it is less work than one big merge that most likely causes some breakage. Of course this does not mean that branches are bad. It only means that you need to be very careful how you use them, especially with the low number of developers. > ideas to keep development active during rc stages is imho next nail in > the coffin of the next major release besides short branch afterlife. Definitely. The alpha->beta->rc-release phase for 2.0 was far too long. The key is to keep this phase as short as possible, then it is less likely that you absolutely need to include this super-important new feature one day before release... Georg
