I started a hit list for 2.2
https://musescore.org/en/developers-handbook/musescore-2.2-hit-list
2017-05-25 1:39 GMT+02:00 Marc Sabatella :
> True. Only the tuplet issue is 2.1-specific as far as I know. I haven't
> tried the fix given by https://github.com/musescore/MuseScore/pull/2880 but
> I
True. Only the tuplet issue is 2.1-specific as far as I know. I haven't
tried the fix given by https://github.com/musescore/MuseScore/pull/2880 but
I'm hoping that merging that and reverting
https://github.com/musescore/MuseScore/pull/2861 would do the job. I need
to get a 3.0 build going again,
The majority of the issues you listed applies to master too. It would then
make sense to fix them in master first. No?
lasconic
2017-05-24 23:37 GMT+02:00 Marc Sabatella :
> I guess my reason for talking about improving our process is to make it so
> if/when the time comes to consider a 2.1.2 as
I guess my reason for talking about improving our process is to make it so
if/when the time comes to consider a 2.1.2 as well, we don't put it off
because our process is still too cumbersome. But I'm OK with not crossing
that bridge until we get to it.
I will see about submitting PR's on 2.2 for
So we are not talking about improving our process here. We are talking
about a 2.1.1.
Let's not overthink it. We have a 2.2 branch, I'm ready to merge any fix in
this branch. We just need to make sure we have nightlies and testers.
lasconic
2017-05-24 22:45 GMT+02:00 Marc Sabatella :
> I wonder
I wonder if maybe there couldn't be a more streamlined process for purely
bug fix releases? Not every release necessarily requires a lengthy
announcement or a newsletter, maybe not all require updating apps, not all
have translation implications, etc.
Because absolutely I agree we shouldn't diver
Alpha -> we have nightly builds
Beta -> we had an RC
-Original Message-
From: byan61 [mailto:brian@verizon.net]
Sent: Wednesday, May 24, 2017 10:03 PM
To: mscore-developer@lists.sourceforge.net
Subject: Re: [Mscore-developer] Releases and packaging
This sounds like QA issue
This sounds like QA issue.
I am relatively new to MuseScore development and releasing process.
Normally software releases go through following stages:
Alpha (internal testing)
Beta (external/user testing)
Final release
All obvious regressions should have been discovered in the Alpha and Beta
rele
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 comm
Note I am not proposing changes to how we do QA. We already have "pretty
good" automated tests (the "mtest") and while we could certainly use more
of them, I'm not suggesting spending effort on that right now. No matter
how good your QA is, regressions happen. The question is, how do you
respond
I'd certainly like to see more frequent releases myself, so I don't have to
maintain a custom build on my own machine.
To that end (and forgive me for my ignorance on these items, I'm largely a
user so I haven't delved into the musescore processes):
- What all goes into packaging a release?
QA is the most challenging thing to get right for a complex software
application. Add the fact that this is open source, and there are no
dedicated QA human resources, and you're in for a challenge. The
primary "establishment" answer to your question is:
1) Maintain an accurate and complete t
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 /
shar
13 matches
Mail list logo
