From: "John Chambers" <[EMAIL PROTECTED]> > > Maybe not. There is a fairly well-established convention in > the computer biz that the first digit should change only > when you break backward compatibility.
Well I must admit I believe that "well established" is a slight exaggeration - different people do all sorts of things. > Of course, such things are merely conventions, and lots of > companies have violated them. A big number change is often > done for marketing purposes, to convince users that it's > something they should spend money on. As you say, especially if they're selling them: in that case changing the second digit is not nearly so good at generating upgrade sales <g>. But no matter, I'm not particularly attached to the idea one way or the other. > The V lines don't > break any pre-existing abc. They are a pure extension, not > a change of any sort. So this should probably not warrant a > jump to a version starting with "2.". I'm too new around here to know what traditional abc apps do when they find a V: line - append it???? > I guess it mostly seems silly to see that we'd be telling > people that there are two versions of abc, 1.6 and 2. In the Windows world we're used to a lot worse: 3.0 - 3.1 - 95 - NT3.1 - NT3.5 - NT4 - 98 - Me - 2000 - XP. A choice between 1.6 and 2.0 would look positively sane. :-) > This sounds like a parody of how computer people do things. Self-parody is a noble art. :-) Anyway to put my oar in the water properly: I am not primarily concerned about whether new developments in abc initially favour one kind of musician or another. (As a sax player I find my needs are rarely considered by anybody - but that's another story.) The reason for my lack of concern is that, having read one or two of the documents I have been pointed at, I see current developments as moving abc towards a point where it can represent a vastly wider selection of music, with V: being the really major development, which people have apparently implemented slightly differently. If abc"1.7" or "2" or "plus" can define a standard for that, and persuade authors to come together to the new standard, then I'm sure further developments will be easier rather than harder. My interest is in having MOZART (initially) import abc. The one thing I *don't* want is to have to do it 23 different ways according to which package wrote the file. So if there is a standard I can read it. If not, then, abc starts to look like something which "would have been nice but...". I am sure many other software authors who have not yet implemented abc will feel the same way, and so a properly defined standard (including V:) may actually make abc take off at a much greater rate - even if it doesn't cover absolutely everything (yet). Casting a (very) fresh eye, over abc, I see various things which I would like it to do (and maybe it does some of them and I have missed it). But I am going to refrain from specific comment a little longer, because I understand Guido is writing a draft standard for "abc plus", which is almost ready to see the light of day. I understand he is trying to maximise compatibility with those who have already extended the standard. Given that he calls it a "draft", it seems that he is inviting comment (and I intend to <g>). I don't know the history of who has written which app, or whether anyone has an axe to grind or not, but given that Guido is actually doing something (which is usually more effective than talking about doing something), I would very much hope that some group of interested parties could coalesce around his draft, and, with that as a starting point, agree on a standard (and how to maintain it as a standard). If I write an abc importer, I don't want people creating files in 6 months time which will break it. If I write an exporter, I would really like the exported files to be readable by as many packages as possible. Next year too. Dave David Webber Author of MOZART the music processor for Windows - http://www.mozart.co.uk Member of the North Cheshire Concert Band http://www.northcheshire.org.uk To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
