Vincent van Ravesteijn wrote: > I'd prefer to continue with the current versioning scheme and introduce > LyX3.0 when there is a significant change, or when we think LyX has taken > another step in maturity.
+1 > Git uses another level in-between, but I think that is a bit too much > given the fact that there are not that many developers testing other one's > features to the bone. We just don't have manpower to do that. git branching is nice for development where you have hundreds of people around. given our number, switch to branch-feature model means you have no testing from others until its gets merged as a whole. > There are certainly benefits. these were all true. i wouldn't divide development on 3 layers though. just keeping experimental branch in a working state would be maintenance burden. > Furthermore, we should have a clear development strategy. We need to > track which features we aim to introduce for the next release, we need > to keep track of the status for each of the features, so we can either > decide to drop the feature or decide to draw attention to it and speed > up development. well, this idea was behind 2.0 as well. the problem is that its very hard to get feedback on the status of features from the POV of release manager. also and typically many people come with some nifty idea without any previous annoucements and merge-only when feature is prepared lacks months testing as written above. to sum it up, these plans all look great on the paper but i dont see it happening when it comes to the daily bazaar here. cathedral needs imho more people around and maybe company-like structure instead of hobbyist doing fun in their spare time. >Now, it happens that there are half-baked features in > trunk... and we have a problem when a release approaches to get them > either in a reasonable state or to remove (disable) them. that would be my responsibility then. in particular what features are you talking about? pavel
