Hi,
First, let me say that I agree that it would be good to have a release to
fix the issues you listed and I do have more or less the same list. We can
discuss this but probably in another thread.
Then, why we don't release more often. This is a multifaceted issue.
1. All the time we (as a community) spend making bug fix release, or point
release, including the time we spend fixing the bugs, we don't spend it
developing the next version of MuseScore. As a personal illustration, in
the past ~6 months, I dedicated most of my time on MuseScore on 2.1, master
has been left aside to a point that I just spent today fixing the nightlies
on Windows, on Mac and AppImage x86_64. Werner has been mainly alone
working on master.
2. Assuming all bugs are fixed, and tested (meaning nightly builds are
being created), translations are done (that's a big assumption) actually
releasing a MuseScore version currently takes around 20 full days but the
time is not spent where you might think.
a. Linux and Mac builds should be built by travis when tagging. That's fast
if the signing certificate are still valid on Mac (it was not the case for
2.1)
b. Windows build is not automated at all. I build the MSI on my computer
(nightlies are built on a server I administer). We can improve on this
point https://musescore.org/en/node/106071
c. For 2.1, we also made a release on the Windows Store but a.b.c. (pure
packaging) can be done in < 2 days. It could be made faster, if we would
release more often since we would detect automation issues more often.
d. Community supported builds: Portable apps, 64bit, noSSE, Linux
distributions (this is still ongoing for MuseScore 2.1)
e. Updating MuseScore website, the update checkers xml files (Thomas does
that), support users with disappearing files (...), no sound on update
etc...
f. Communicating the release. Draft the release notes, the announcement, a
newsletter, update the different online directories (kdeapp, macupdate
etc...). For MuseScore 2.1, we sent the newsletter yesterday, partly
because it needs to be written, partly because we want to make sure that
the release is not completely broken, partly because it's better if we have
Portable, x64 version (PPA) if we don't have to have dozens of support
emails.
g. Updating all the other projects that depends on MuseScore itself :
MuseScore apps (released yesterday on android and today on iOS) &
MuseScore.com backends.
3. Testing. If we have this discussion, it's because there are still
annoying bugs in MuseScore 2.1. Still, we have tests (mtest + vtest) but
never enough... The tuplet corruption should have been detected by tests.
Then, we have nightlies. I spent quite some time making sure that we do
have nightly builds being created in order to be tested. Unfortunately we
don't have enough "expert" eyeballs using these nightly builds. We should
probably make the status of the nightlies clearer, meaning they are
documented as extremely unstable which was not the case for nightlies just
before 2.1. Also, we should have an automated way to update nightlies.
Ok. That was lot of text. I will read the other answers now :)
lasconic
2017-05-24 18:48 GMT+02:00 Marc Sabatella <[email protected]>:
> Generally speaking, we don't release bug fix updates as often as some
> projects do, and I get the sense that a big reason for this is how much
> work
> is involved in actually producing packages for release. On the assumption
> that this is in fact the case, I'm wondering, what can we do to lessen /
> share this load?
>
> I ask because, as is often the case with a relatively big release, there
> are
> a small number of very unfortunate regressions in 2.1 that are being
> reported over and over, and I would like to be able to address them. I
> believe we understand these issues well enough to be able to fix them
> quickly, and as far as I am concerned doing this is worth a certain amount
> of pain on our part. I think as the user base of MuseScore grows and the
> applications continues to be taken more seriously, we need to be
> increasingly conscious of how responsive we are.
>
> I think we probably all have a sense of what I am talking about, but
> specifically, I have in mind:
>
> - tenor drum silent due to mix up between soundfont and instruments.xml
> - loud pops in some sounds due apparently to a fix for a different issue
> - inability to enter rests by mouse on drum staves
> - corruption on copy/paste (or save/load) of any non-reduced tuplet
> - loss of information on "regroup rhythms" (at least, we should preserve
> enharmonic spelling)
> - maybe add a note to the save online dialog mentioning the dependency on
> LAME for custom audio?
>
> I realize that currently, producing a new release basically comes down to
> lasconic doing a whole ton of work mostly on his own, and I greatly
> appreciate all he has been doing keeping things running as smoothly as they
> have been. But I think it is high time we look at improving this
> situation.
> I'm not saying we should spend a lot of time putting out new releases every
> month or whatever, but I do think we need to have a better strategy than we
> do right now.
>
>
>
> --
> View this message in context: http://dev-list.musescore.org/
> Releases-and-packaging-tp7580247.html
> Sent from the MuseScore Developer mailing list archive at Nabble.com.
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Mscore-developer mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mscore-developer
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Mscore-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
