Quantcast

The roadmap to MuseScore 1.0

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

The roadmap to MuseScore 1.0

Thomas Bonte
Administrator
As you may have noticed, the MuseScore project has been branched when 0.9.6 was released. The main reason for this decision was that Werner wanted to perform some major refactoring and at the same time, Nicolas (lasconic) wanted to fix incoming critical bugs on 0.9.6. The status today is that the trunk comes with new major features such as tablature support and linked part editing, and the branch has never been so stable before with its 0.9.6.3 release. So how do we go further from here?

One of the open challenges is to get MuseScore to its 1.0 release. Many people might not have tasted from MuseScore yet because they are waiting for the stable 1.0 release. Music education for example. The 1.0 label will be an important sign for them to finally give MuseScore a try. To release 1.0, we have basicly two options:
1.  Create a new release on the 0.9.6 branch and call it 1.0. At the same time we release a prerelease for the current trunk which could eventually end up being the 2.0 release
2.  We further develop the current trunk and make it eventually the 1.0 release.

There are pro’s and con’s for each option but after having some chats with Werner and Nicolas, we would opt for option 1. The main reason is that the current trunk has seen a lot of changes. This simply means that it will take a lot of time before it will reach the stability stage we have today with the 0.9.6.3 branch. Add to this that the documentation has to be updated quite a bit and that the translations need to be updated as well. The current state of the 0.9.6 branch is simply to good not to leverage it and to use it to drive the MuseScore adoption in the market.

If you have questions or remarks, please don’t hesitate to leave a comment.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The roadmap to MuseScore 1.0

David Bolton-2
I don't have strong feelings about the version numbers. I think the
number 1.0 is meaningful to open source enthusiasts and maybe some
technically-oriented educators. On the other hand, a significant number
of people on the forums do not even notice the initial zero and report
that they are using version 9.6.3 for example.

I am in favor of limiting version numbers to three digits once we are
done with the 0.9.6.x series (four digits is too many to remember).
However, I think the decision to branch the stable release was probably
the most important factor in making the current release the most stable
to date. The branch allowed for bugs to be fixed after the initial 0.9.6
release.

I know that future development cycles won't always be as ambitious as
the current trunk, but I recommend that we branch for every future
stable release. Software of this complexity always has bugs that aren't
discovered/reported until after the release. The possibility to offer
bug-fix-only releases on stable versions would mean that users can
continue to enjoy the stability they have come to expect from the
0.9.6.x series.

David


On 11/30/2010 2:39 AM, Thomas Bonte wrote:

> As you may have noticed, the MuseScore project has been branched when 0.9.6
> was released. The main reason for this decision was that Werner wanted to
> perform some major refactoring and at the same time, Nicolas (lasconic)
> wanted to fix incoming critical bugs on 0.9.6. The status today is that the
> trunk comes with new major features such as tablature support and linked
> part editing, and the branch has never been so stable before with its
> 0.9.6.3 release. So how do we go further from here?
>
> One of the open challenges is to get MuseScore to its 1.0 release. Many
> people might not have tasted from MuseScore yet because they are waiting for
> the stable 1.0 release. Music education for example. The 1.0 label will be
> an important sign for them to finally give MuseScore a try. To release 1.0,
> we have basicly two options:
> 1.  Create a new release on the 0.9.6 branch and call it 1.0. At the same
> time we release a prerelease for the current trunk which could eventually
> end up being the 2.0 release
> 2.  We further develop the current trunk and make it eventually the 1.0
> release.
>
> There are pro’s and con’s for each option but after having some chats with
> Werner and Nicolas, we would opt for option 1. The main reason is that the
> current trunk has seen a lot of changes. This simply means that it will take
> a lot of time before it will reach the stability stage we have today with
> the 0.9.6.3 branch. Add to this that the documentation has to be updated
> quite a bit and that the translations need to be updated as well. The
> current state of the 0.9.6 branch is simply to good not to leverage it and
> to use it to drive the MuseScore adoption in the market.
>
> If you have questions or remarks, please don’t hesitate to leave a comment.


------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The roadmap to MuseScore 1.0

Maurizio M. Gavioli
In reply to this post by Thomas Bonte
While I personally tend to share David's opinion about version numbers, I agree with Thomas that, in the 'big world out there', version numbers have an impact on the recognition of an application.

I agree that MuseScore deserves to be a greater player among music notation programmes that it is now. And I understand that the developers who spent so much time on it also deserve it.

However, I suspect that, if a 0.x programme might be praised for any feature it contains, a 1.x programme risks greatly to be blamed for anything 'important' it lacks.

While what is important and what it is not tends to be a subjective matter, I believe that the clustering of forum posts around some topics may be a reasonable indication.

My guess is that the current stable versions falls short in two major areas:

1) Documentation: the current .pdf still has not been completed with some of the recent additions and it also lacks entire chapters (or paragraphs), like part creation or a clear explanation of the page / style formatting options. I would not suggest releasing a version 1.0 with this documentation (not even a version 0.9.7, methink).

2) Some of the features added to the trunk. This again is rather subjective, but one indication might be the number of requests for a better dealing with multi-piece scores; other may indicate a few other aspects (very few!).

(Note: the trunk has a greatly better handling of multi-piece scores; it would not be necessary to include all of it: pagination start number and contextual "Hide courtesy <...>" menu items for key and time signatures are probably enough: a handful of well tested code lines to copy and a handful of strings to translate.)

A last point can be backward compatibility: while the trunk version will for sure attempt to keep it as much as possible, it is not sure it will be possible in all and each detail (for instance, texts with style and/or in frames or page numbers (=> header / footer) have a rather different structures and automatic conversion might be not always possible).

Now, having a version 1.0 (<= branch) now and a version 2.0 (<=trunk) within a few months without total backward compatibility might be an unwise move for the acceptation of MuseScore.

So, probably, the above hints at releasing a version 0.9.7 from the current branch, once addressed point 1) and 2) above, and going on with 1.0 dev from the trunk.

Of course, just an opinion...

Thanks,

M.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The roadmap to MuseScore 1.0

J.L. Blom
In reply to this post by Thomas Bonte
On 30/11/10 09:39, Thomas Bonte wrote:

> As you may have noticed, the MuseScore project has been branched when 0.9.6
> was released. The main reason for this decision was that Werner wanted to
> perform some major refactoring and at the same time, Nicolas (lasconic)
> wanted to fix incoming critical bugs on 0.9.6. The status today is that the
> trunk comes with new major features such as tablature support and linked
> part editing, and the branch has never been so stable before with its
> 0.9.6.3 release. So how do we go further from here?
>
> One of the open challenges is to get MuseScore to its 1.0 release. Many
> people might not have tasted from MuseScore yet because they are waiting for
> the stable 1.0 release. Music education for example. The 1.0 label will be
> an important sign for them to finally give MuseScore a try. To release 1.0,
> we have basicly two options:
> 1.  Create a new release on the 0.9.6 branch and call it 1.0. At the same
> time we release a prerelease for the current trunk which could eventually
> end up being the 2.0 release
> 2.  We further develop the current trunk and make it eventually the 1.0
> release.
>
> There are pro’s and con’s for each option but after having some chats with
> Werner and Nicolas, we would opt for option 1. The main reason is that the
> current trunk has seen a lot of changes. This simply means that it will take
> a lot of time before it will reach the stability stage we have today with
> the 0.9.6.3 branch. Add to this that the documentation has to be updated
> quite a bit and that the translations need to be updated as well. The
> current state of the 0.9.6 branch is simply to good not to leverage it and
> to use it to drive the MuseScore adoption in the market.
>
> If you have questions or remarks, please don’t hesitate to leave a comment.
>    
Thomas,
Nice to hear progress is steady and making a stable Linux score program
is for many a necessity.
I follow the development of MuseScore from the side but don't use it
currently  as I miss several implementations.
At this moment Musescor has only what is called "Page Mode", where - as
in the old days with paper and pen - the music is written on sheets.
However, many, especially arrangers, use what is called "Scroll mode"
where all staffs can be displayed continuously , scrolling from left to
right (or vice versa!) where you don't have to worry about lay-out etc.
Another problem I have is that in the version I use (Linux ubuntu 10.04)
the 4 layers are not functioning. For example, I always write my chords
on layer 4 but for the part for a singer, chords are not needed. I write
in concert pitch but when separating  the parts for the different
instruments, I copy this layer 4 to each instrument after which I
transpose to instrument pitch. I tried it in MuseScore but didn't succeed.
Those are at the moment the main reasons I cannot use MuseScore but as
soon as it is possible I will switch from my current Score-program
(Finale Windows only!) to MuseScore. Hope that day will arrive soon.
I'm sorry I can not contribute better as my programming skills were on a
much older language (Fortan, Pascal) and not used for many years.
I hope you can do something with my comments, the best gem of MusScore
is it use of musicxml as exchanging between different platforms is now
very easy.
Keep up the good works!
Joep


------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The roadmap to MuseScore 1.0

Leon Vinken
In reply to this post by Thomas Bonte
Given the feature set and stability of the current 0.9.6.3 version, I think it is certainly good enough to call it "1.0". As, indeed, some people are reluctant to try software numbered 0.something, releasing 1.0 may give us more users.

IMHO we should define what goes into 1.0 (bug fixes, small changes, big changes ?) and when to start code freeze and testing a.s.a.p.

My preference would be to have a 1.0 based on 0.9.6.3 containing bug fixes and small changes soon. This release should be as stable as 0.9.6.3. I would like the bww importer to be included. This is low risk, as it does not affect any core code.

Regards, Leon.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The roadmap to MuseScore 1.0

Maurizio M. Gavioli
IMHO, Leon's arguments make sense, as well as original Thomas' arguments did and I begin to agree that waiting for the trunk to become version 1.0 may take too long.

I still believe that, to bring current 0.9.6.3 branch to 1.0:

1) Current documentation should be completed in certain parts / polished in other (I'm sorry not to be of particular help in this for lack of specific skills and for linguistic marginality)

2) A well-chosen set of additional features in the code (presumably from the trunk) will reduce complains / pressure on the forum / user support in general (my proposal about this ( http://musescore-developer.685061.n2.nabble.com/Status-of-brach-new-text-strings-small-features-td5847810.html ) is still on the table).

I also agree with Leon that defining what goes into 1.0 soonish is important.

Thanks,

M.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The roadmap to MuseScore 1.0

Thomas Bonte
Administrator
In reply to this post by Thomas Bonte
Thank you all for your comments. First of all, I'm happy to read in most comments that there is a general good feeling about releasing MuseScore 1.0. This will be a huge step for our project. In this post I will not address particular feature requests, but instead focus on the roadmap to 1.0. But let’s start with clearing up some issue which were raised in the comments.

State of the current branch

As indicated by Miwarre, the current branch falls indeed short on several aspects, such as documentation and features for pro users.

Many new pro features are already implemented in the current trunk. Unfortunately, it would be to hard to backport to the branch. Werner & Nicolas has expressed to keep the 0.9.6.x branch for critical bug fixes only and spend time on stabilizing the current trunk.

Scanning the forum, one can indeed conclude that the documentation falls short on some topics such as parts, text styles and more. Interestingly enough, it has been a deliberate action not to write these out since these features half baked in the branch. On the other hand, I would even like to state that the documentation written by the community will always lag behind. It simply can't address all the use cases, needs and wishes from all type of musicians using MuseScore. My personal action point for 2011 to get this fixed by looking for technical writers who want to write books for MuseScore. And one more thing: by releasing 1.0, the community will grow and new people will present themselves to further extend the documentation.

Version numbering

As raised by David, the current version numbering is too long. So from 1.0 on, we'll use only 2 numbers: X.Y

Future development

In the current development state of MuseScore, we have a branch  maintained by Nicolas on which critical issues are fixed and there is a trunk maintained by Werner for the active development. While it's hard to see in the future, in terms of available resources, the current intention is to maintain this development structure: one branch which is maintained for critical bug fixes and a trunk on which active development is performed.

Backward Compatibility

The plan is to be backward compatible to 0.9.6.x as good as possible. As far as Werner can see this should be possible. In case some layouting can not be preserved, we can always add a dialog box which informs the users about which elements of parts in the layouting needs a double check.

The MuseScore 1.0 roadmap

Our goal would be to release MuseScore 1.0 at the end of January 2011, so that gives us around 5 weeks.

December
We’ll accept very small, non intrusive and high impact changes on the 0.9.6.x branch and will address them on an individual basis. So post your patches in http://musescore.org/en/project/issues/musescore and mention [1.0] in the title so we can easily list up the issues related to the 1.0 release.

January week 1-2
A 1.0 beta will be made available to test the changes. Translators will be mailed to update the translations.

January week 3
Release of a 1.0 RC.

January week 4
Release of MuseScore 1.0.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The roadmap to MuseScore 1.0

Thomas Bonte
Administrator
In reply to this post by Thomas Bonte

Thank you all for your comments. First of all, I'm happy to read in most
comments that there is a general good feeling about releasing MuseScore 1.0.
This will be a huge step for our project. In this post I will not address
particular feature requests, but instead focus on the roadmap to 1.0. But
let’s start with clearing up some issue which were raised in the comments.

State of the current branch

As indicated by Miwarre, the current branch falls indeed short on several
aspects, such as documentation and features for pro users.

Many new pro features are already implemented in the current trunk.
Unfortunately, it would be to hard to backport to the branch. Werner &
Nicolas has expressed to keep the 0.9.6.x branch for critical bug fixes only
and spend time on stabilizing the current trunk.

Scanning the forum, one can indeed conclude that the documentation falls
short on some topics such as parts, text styles and more. Interestingly
enough, it has been a deliberate action not to write these out since these
features half baked in the branch. On the other hand, I would even like to
state that the documentation written by the community will always lag
behind. It simply can't address all the use cases, needs and wishes from all
type of musicians using MuseScore. My personal action point for 2011 to get
this fixed by looking for technical writers who want to write books for
MuseScore. And one more thing: by releasing 1.0, the community will grow and
new people will present themselves to further extend the documentation.

Version numbering

As raised by David, the current version numbering is too long. So from 1.0
on, we'll use only 2 numbers: X.Y

Future development

In the current development state of MuseScore, we have a branch  maintained
by Nicolas on which critical issues are fixed and there is a trunk
maintained by Werner for the active development. While it's hard to see in
the future, in terms of available resources, the current intention is to
maintain this development structure: one branch which is maintained for
critical bug fixes and a trunk on which active development is performed.

Backward Compatibility

The plan is to be backward compatible to 0.9.6.x as good as possible. As far
as Werner can see this should be possible. In case some layouting can not be
preserved, we can always add a dialog box which informs the users about
which elements of parts in the layouting needs a double check.

The MuseScore 1.0 roadmap

Our goal would be to release MuseScore 1.0 at the end of January 2011, so
that gives us around 5 weeks.

December
We’ll accept very small, non intrusive and high impact changes on the
0.9.6.x branch and will address them on an individual basis. So post your
patches in http://musescore.org/en/project/issues/musescore and mention
[1.0] in the title so we can easily list up the issues related to the 1.0
release.

January week 1-2
A 1.0 beta will be made available to test the changes. Translators will be
mailed to update the translations.

January week 3
Release of a 1.0 RC.

January week 4
Release of MuseScore 1.0.
--
View this message in context: http://musescore-developer.685061.n2.nabble.com/The-roadmap-to-MuseScore-1-0-tp5787395p5855401.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The roadmap to MuseScore 1.0

Maurizio M. Gavioli
In reply to this post by Thomas Bonte
News from Thomas are terrific!

Two points:

1) Schedule seems to me a bit too tight:

* from today (almost tomorrow!) to end of month there are 9 days, with some trifle in between like Christmas...
* 1 week for testing the RC seems quite short (if I remember correctly, between RC1 and release for 0.9.6 there has been more or less a month and another RC (or two?) )

2) I may be docu-maniac but I am not convinced by Thomas' arguments about documentation.

For an open source project to be acceptable that documentation lags behind and does not cover special applications or needs of pro users is one things.

Releasing a version 1.0 with a manual which does not mention whole menus or central dlg boxes like page settings, styles, part extraction (topics for which support requests abound in the forum) and so on is another thing.

The fact that some parts of these components are going to change in the next version is not important for the user who needs to discover how to do things with *this*version.

Is it the case to re-evaluate the impact that an incomplete documentation can have on the acceptance of a version 1.0? (particularly in the educational milieu which has been explicitly indicated as a relevant target).

MuseScore users show a great variety of backgrounds and formations (and most of them know something about music, which doesn't hurt): isn't conceivable that someone among them has the skills needed to produce some documentation and to fill at least the most important 'holes' in a timely fashion? This is a collaborative, open source (and open mind) project: let's take advantage of it.

With best wishes for incoming vacations,

M.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

The road to MuseScore 1.0: translation time

Thomas Bonte
Administrator
In reply to this post by Thomas Bonte
Dear MuseScore friends,

Let me first start with wishing you all a Happy New Year. While 2010 was a tremendous year for MuseScore, 2011 will prove to be even more exciting with the release of MuseScore 1.0. If you speak another language besides English, you can help make MuseScore 1.0 the best release ever.

All the outstanding bugs for 1.0 have been fixed thanks to the dedicated work of Leon, Miwarre, David, Nicolas and Werner. Now it's time to update the translations. Here is how you can help.

The software
While fixing bugs for 1.0, some strings where altered or added. Head over to http://translate.musescore.org/ and get your language up to 100%.

The handbook 
- One new page was added about "Part extraction": http://musescore.org/en/node/8512
- Check the handbook translation status at: http://musescore.org/en/admin/content/translation_overview_assignments

Deadline
In 2 weeks (January 20th), we will package a MuseScore 1.0 beta release. If that release doesn't reveal any bugs, nothing can stop us to release MuseScore 1.0 before the end of the month.

If you have question, don't hesitate to leave a post on the translator forum:
http://www.musescore.org/en/forum/9
Loading...