@lasconic
Always the same answer...
I signed the CLA, translated polish, etc. I want to know approximate date of candidate release - this week, this month?
8th February, the first strings were added to translate. https://musescore.org/en/node/270029 - for two days, the strings are freezed.
These answers satisfy me:
- "We don't know"
- "X weeks/months and will be ready"
- etc.
@Jojo-Schmitz
Yes, it's a good idea. But I want to know 'more official' date than "When it will be ready".
X - some 'real' number :D
Greetings,
Gootector
--
@lasconic
Do you understand differences between your "When it will be ready" and "We don't know" or "X weeks/months and will be ready"? Your answer is ironic. For me, sounds like: "Buzz off! I'm working and I don't have the time to answer!". Conversation with Jojo-Schmitz is 'more friendly'. I wished to no offend You, lasconic. It's all.
It might sound ironic, but it's not. We are working on it, we are working towards a date but we will really release 2.2 when it will be ready. Typically string freeze happens a small number of weeks before the release.
There is a list of bugs here https://musescore.org/en/handbook/musescore-22-hit-list
One thing I have noticed is that most commercial projects have schedules that are driven by management based on marketing concerns. That is, they decide they need a release in some specific month, so that date is announced internally and everyone works to release by then, deciding what bugs to fix and what features to add based on that date. Meaning you get software released by a predictable date but with unpredictable quality and functionality. Open source projects tend to work the other way around - the list of bugs to fix and features to add is decided first, and then however long that takes determines the release. Meaning you get software with predictable quality and functionality but unpredictable release date. That's actually a good thing to me and I think to most users.
Of course, that description is kind of over-simplified and the real world is often more complex. But still, the basic idea holds: when open source projects say something will be released when ready, that means exactly what it says, because the schedule is determined by how long it takes to achieve the desired quality and functionality and is not set arbitrarily in advance by management/marketing.
"Open source projects tend to work the other way around... unpredictable release date."
Actually, that's not correct. The largest projects, including Firefox, LibreOffice, and some major Linux distributions, often have regular release cycles with target dates determined well in advance.
True indeed for those projects, but still, a few high-profile / large-scale exceptions don't mean it isn't true in general. I would wager the vast majority of open source projects are not like that. I suspect that the bigger a project and more bureaucratic a project gets, the more likely it is to gravitate to the corporate model.
To be sure, most open source projects don't have enough development activity to make it feasible. I suspect few open source projects have as much development activity as MuseScore. ;-)
Comments
When it will be ready.
Until then just use a 2.2 development build
I've copied all the stuff from the latest into a 2.1 portable app (and renamed nightly.exe to MuseScore.exe) and am using that quite happily.
In reply to Until then just use a 2.2… by Jojo-Schmitz
@lasconic
Always the same answer...
I signed the CLA, translated polish, etc. I want to know approximate date of candidate release - this week, this month?
8th February, the first strings were added to translate.
https://musescore.org/en/node/270029 - for two days, the strings are freezed.
These answers satisfy me:
- "We don't know"
- "X weeks/months and will be ready"
- etc.
@Jojo-Schmitz
Yes, it's a good idea. But I want to know 'more official' date than "When it will be ready".
X - some 'real' number :D
Greetings,
Gootector
--
@lasconic
Do you understand differences between your "When it will be ready" and "We don't know" or "X weeks/months and will be ready"? Your answer is ironic. For me, sounds like: "Buzz off! I'm working and I don't have the time to answer!". Conversation with Jojo-Schmitz is 'more friendly'. I wished to no offend You, lasconic. It's all.
In reply to @lasconic… by Gootector
It might sound ironic, but it's not. We are working on it, we are working towards a date but we will really release 2.2 when it will be ready. Typically string freeze happens a small number of weeks before the release.
There is a list of bugs here https://musescore.org/en/handbook/musescore-22-hit-list
In reply to @lasconic… by Gootector
One thing I have noticed is that most commercial projects have schedules that are driven by management based on marketing concerns. That is, they decide they need a release in some specific month, so that date is announced internally and everyone works to release by then, deciding what bugs to fix and what features to add based on that date. Meaning you get software released by a predictable date but with unpredictable quality and functionality. Open source projects tend to work the other way around - the list of bugs to fix and features to add is decided first, and then however long that takes determines the release. Meaning you get software with predictable quality and functionality but unpredictable release date. That's actually a good thing to me and I think to most users.
Of course, that description is kind of over-simplified and the real world is often more complex. But still, the basic idea holds: when open source projects say something will be released when ready, that means exactly what it says, because the schedule is determined by how long it takes to achieve the desired quality and functionality and is not set arbitrarily in advance by management/marketing.
In reply to One thing I have noticed is… by Marc Sabatella
"Open source projects tend to work the other way around... unpredictable release date."
Actually, that's not correct. The largest projects, including Firefox, LibreOffice, and some major Linux distributions, often have regular release cycles with target dates determined well in advance.
In reply to "Open source projects tend… by Isaac Weiss
True indeed for those projects, but still, a few high-profile / large-scale exceptions don't mean it isn't true in general. I would wager the vast majority of open source projects are not like that. I suspect that the bigger a project and more bureaucratic a project gets, the more likely it is to gravitate to the corporate model.
In reply to True indeed for those… by Marc Sabatella
To be sure, most open source projects don't have enough development activity to make it feasible. I suspect few open source projects have as much development activity as MuseScore. ;-)
https://musescore.org/en/node/270419
In reply to https://musescore.org/en… by Isaac Weiss
Thanks, Isaac :D