Feature Freeze
I wondered whether the feature freeze (mentioned here ) could be delayed beyond 2 months. Combined with the long list of feature requests and doing other tasks (e.g. transcribing the Goldberg Variations), there might not be enough time. I was just thinking so we can get as much as possible feature-wise into 2.0, before considering the stability stage. I don't know if there's plans to postpone certain things for 3.0 though (perhaps also depending on Qt, or other issues).
Is feature implementation a priority over bugs just now?
Thanks :).
Comments
I think Werner is just about finished adding his needed features for the Goldberg project, judging from the changes coming in the trunk. I suspect the first phase of the Goldberg transcription is done.
MS 1.0 was released in Jan/Feb 2011, 1.1 just now in July, so putting a feature freeze into the trunk (2.0) could put a release around December, and at the same time start a new round of feature additions for 3.0.
Personally, I agree with you. Delay the freeze for a few (2?) more months, get some more major features implemented, then bugfix for 4 months. This would put the 2.0 release around Feb 2012, one year past 1.0. The trunk is just barely (to me) getting usable again after the massive code overhaul and additions.
In reply to I think Werner is just about by schepers
We are at the end of July;
2 months from now => end of September;
2 more months => end of November;
4 months of bug fix => end of March.
I have no clear idea, but I suspect arriving at end of March for ver. 3 might be considered a bit late (also, planned released dates tend to shift...).
A kind of compromise could be to arrive at the end of September (original feature freeze date) with a list of features agreed upon (by whom? mainly Werner, I presume) even if not all of them are at that moment implemented and freeze this list.
Of course, we should not 'cheat' on the list; i.e. we should not fall in the trap to insert in the list the whole Universe "and much more...", but only features which may reasonably get implemented (and debugged) in the planned time.
M.
In reply to We are at the end of July by Miwarre
It depends how long it takes to implement or fix something. I thought about 3 months for features and 3 months for stability (some may not agree though) - that would take us into February.
I do like the idea of having a major release every February (with 'minor' releases until the next). Obviously things don't always go to plan (especially if it ends up taking longer, or you are depending on Qt, etc), and it's very unlikely we'll get everything in. Instead, perhaps the feature requests list could be trawled through and select certain things.
I also don't know if 2.0's coding will continue in 3.0, or if it will start again. If it does just continue, then we could get both features and bug fixes in each release, regardless of version numbering?
I feel that two months for new features seems about right. I mean, 2.0 already has a ton of stuff I really would rather not wait any longer than necessary for (real styled text, linked parts), and relatively little I'd expect to still be missing after two months - certainly, not that I'd consider so important that it couldn't wait until the *next* release after 2.0. While the list of requested features might seem like it is growing and not shrinking, realize that a good chunk of the effort for the last few months has been in other areas (eg, the 1.1 release, also musescore.com-related work). If the Goldberg stuff is really almost done, you might be surprised at how many other items on the list might get checked off in two months.
But even if some things one might want don't make 2.0, I don't see that as a bad thing. I know linked parts required some significant architectural changes, I think tablature support probably did too, plus I know there was some major refactoring of the trunk to better support the possibility of building different UI's (eg, tablet apps) on top of the same basic backend. I don't have any insight into long term plans, but I am not aware of anything so major being planned for after 2.0. So I'm not sure there would need to be that long of a wait after 2.0 for the next release that actually added new features - a 2.5, say, that could come out within maybe six months of 2.0. Just speculating here, of course.
But I'm sure the two month window isn't set in stone, either. If it feels like there's still too many important features left, it's not like there are some sort of corporate bean counters who are going to force them to freeze anyhow just to get release out the door by a specific date (as I've seen happen many times in the commercial world, both as a producer and consumer of software).
In reply to I feel that two months for by Marc Sabatella
Agreed
I must admit, I'm not too bothered by features at the moment. My concern is more towards bugs. Perhaps there could be emphasis on those, with anything else in the feature requests (general and advanced features) left for versions after.
What's the latest?
In reply to What's the latest? by chen lung
Good question. But I just wanted to say - and this as good a place as any to say it - that having just started checking out the nightly builds for the first time in several months, they are looking quite nice. Obviously, still plenty of rough edges in implementation when you dig deeper, but it does feel like a nicely improved feature set that is cleanly presented.
I haven't played around enough with any of the new stuff to say what specific features I think are still missing, but if there is one thing I yearn for most in 1.1 that I suspect is not sufficiently addressed yet in 2.0, it is more control over layout and appearance of scores. Things like being able to increase the space between two staves within a system throughout the score (as opposed to having to do so individual for each system), ability to mark some staves as completely hidden for playback only, ability to control the hiding of staves within a system individually, ability to nudge text, chordname, dynamics, and similar elements by keyboard both horizontally and vertically, ability to set bar line styles for the left and right barline independently (so I can force a system to *start* with a double bar, for instance). These are all things I've mentioned or raised issues for before, and individually, no single one of them stands out to me. But collectively, under the umbrella of "control over layout and appearance", this is definitely the area I feel where additional features would be most welcome.
I should also acknowledge that there have been some pretty significant strides already here, though. So I'm not saying there definitely needs to be any more work in this area for 2.0. It might just as well make sense as a push for the next release. But anything that could be done sooner rather than later would be great.
Are we waiting until after Qt 4.8 to be released for the feature freeze?
Could be a good idea actually.