On 09/22/11 16:02, Joe Emenaker wrote: > On 9/21/2011 11:19 PM, Roger Westerlund wrote: >> 2011/9/20 William Zwicky<[email protected]>: >>> On Mon, Sep 19, 2011 at 11:28 PM, Roger Westerlund >>> <[email protected]> wrote: >>>> Or why don't we release a 1.0. That would be a bold move. >>> 3.11 Enterprise Edition. Comfortable now? > Let's do it like Chrome, where we roll out a new major version number > every couple of weeks! :) > >> I believe we decide when we are stable. I have a hard time believing >> that during the 10 years JSL has lived that we have not been in a >> "stable" state at some point. And if we haven't, will we ever be >> stable? > Well, it *was* fairly stable, in times passed, but right now isn't one > of those times. > >> Big refactorings of the core is a major version leap. It would be a >> good thing to have a "stable" release before the big refactoring since >> big refactorings tends to need time for stabilizing (it's a fact). Why >> not call that release 1.0 and we can let the big refactoring mature in >> parallel to become 2.0? > I agree that that's a possibility; that we could call the existing code > "1.0" and then use "2.0" for the refactoring. It just didn't really turn > out that way. > > Now, I think I get your point about version numbers and public > perception. Whenever I'm browsing Sourceforge, and I see a version > number like "0.10" or "0.28", I figure that the software is still only > in its "proof of concept" stage, that most features are unimplemented, > many things don't work right, and that it crashes frequently. In short, > I figure that it will be more frustrating to try to use it that it would > be to not use it at all. > > JSL isn't quite *that* bad, but I do find the UI to be very > counter-intuitive and I see lots of run-time exceptions thrown in the > console. If "1.0" is earned just by merely doing something useful and > doing it fairly reliably, then I'd put the current code at about 0.85 or > 0.90. > > I do rather like the Roger's bold idea of calling it 1.0 to coincide with the 10 year anniversary. Having said that my feeling is that the software is beta level - a lot of it works fine but some bits are dodgy so perhaps not deserving of 1.0. Given the number of bugs I've easily found, I would expect that there are more lurking in there that I haven't run across yet.
On the subject of bugs, as input to this discussion and I guess to help with the 0.21 release notes, I have been through the cvs list and made a list of user-visible fixes/changes since I subscribed to the jsl mailing lists at the end of august; no doubt there have been various other patches since the 0.20 release but the sf.net web interface is too much of a PITA to look back through 6 years of cvs list archives! Predominantly these are bug fixes and usability improvements. bug/crash ------------------------------------- DX7 voice editor fix recover better from corrupt prefs correct unfussy regexes for various synths' autoscan table selection issue after removing duplicates from library fixed possible crash when number of midi devices decreases and do a better job at maintaining port settings usability enhancement ------------------------------------- multiple midi interface fix images for TX81z waveforms keyboard shortcut for new patch excessive exit confirmations remember location of main window improved delete duplicates dialogue box(es) look and feel defaults to nimbus improved display/naming of midi devices functionality enhancement ------------------------------------- DX100/TX81z envelope improvement librarian support for SY77 M350 librarian/editor single driver for SY85 improved matching up sysex with supporting drivers (scan more than just header) frankie ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ Jsynthlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
