On Sat 20 May 2017 at 18:38:24 (+1000), Andrew Bernard wrote:
> I have used the development versions full time 8 hours plus a day for the
> last few years, with only two trivial crashing bugs, on massively complex
> scores.
Stable has more than one meaning. 2.18.2 has been stable for a long
time, and promises to be around a lot longer seeing that Debian's
"stretch" (as yet unreleased) still includes it.
For five minutes of mental exercise this Saturday morning, I cobbled
a line of shell¹ to see how many development versions of LP were talked
about here over the last year. There are rather a lot, and you've
quite probably tracked them all.
I think that if "ordinary people" are encouraged to use development
versions, then there needs to be another level introduced on the web
page between bleeding-edge and stable; perhaps "trailing-edge".
These would be the development versions (only one need be offered at
any one time) that over time have shown they don't contain egregious
mistakes (eg like broken lyric extenders).
I hope 2.19.49 (the version I currently use) is one of these.
I run LP regularly on three different machines and don't want
to be perpetually downloading and installing new versions even
though it's only two lines to do so (two more for the docs).
When preparing several pieces over the course of a few weeks,
even the smallest change can destabilise, say, the pagination,
which is most inconvenient.
> Here the OP is using the so called stable version and it has
> crashed straight up.
If the reported diagnosis is correct (locked output file), this
is not a function of stable/unstable LP, but a property of the
OS being used. A "kiosk" computer user (eg ATM) is constrained
to do one thing at a time. Anyone else has to understand the
properties of the OS they use.
With linux-type OSes, you get used to what happens when you,
say, refresh a PDF that's being written to. When it matters,
eg email clients, there are file-locking methods that are used
to prevent file corruption.
On Windows, it's different. Most processes lock files that are
being written to, and even files that are only being read can
have problems with being shared.
> On 20 May 2017 at 18:11, Richard Shann <rich...@rshann.plus.com> wrote:
> >
> > The harm is that users assume the problem is with their code and spend a
> > lot of time trying to find what they have done wrong.
Agreed.
Cheers,
David.
¹
$ grep '\<2\.19\.[0-9]' ~/Mail-alum/lilypond-user | sed -e
's/.*\(2\.19\.[0-9]\{1,2\}\).*$/\1/' | lcount.py | sort -n | tail -n 28 | sort
-k 2
192 2.19.0
140 2.19.15
87 2.19.22
50 2.19.35
173 2.19.36
59 2.19.37
87 2.19.38
121 2.19.39
223 2.19.40
82 2.19.41
246 2.19.42
124 2.19.43
468 2.19.44
242 2.19.45
329 2.19.46
330 2.19.47
452 2.19.48
542 2.19.49
241 2.19.50
92 2.19.51
518 2.19.52
196 2.19.53
200 2.19.54
277 2.19.55
219 2.19.56
125 2.19.57
191 2.19.58
231 2.19.59
$
"Talked about", so the counts include quotations as well as OPs.
No control for multipart email duplicates, nor omissions through encoding.
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
