Alright Jeremy I'll bite one this one. Of course, I think that some of my statements are a little nebulous (good cannon fodder)... In message "RFC: Wine 1.0", you write: >Given the amount of progress Wine has made over the past year, >it seems (to me anyway) that the time may be appropriate to >try for Wine version 1.0. > >I was hoping to spark a conversation on this topic, in two basic areas: > 1. Should we do it? (If not, why not, and when?) I would say that if we do it, it can mean one of the following two things: 1) We think that enough progress has been made on Wine since its infancy then it's a psychological type of thing. It doesn't have to imply that it's stable just that it's a good basis for what we're going to do in the future - big features done. Perhaps start by releasing a Wine 0.9 type of thing - or just call it 1.0 (most of which are generally buggy products anyways). 2) We have a "somewhat stable" version which we think we can handle having people run for ages. We've made the decision to perhaps fork off a bug fix stream or start with multiple streams. We've also made the decision that we're going to have pseudo periodic "releases" which are of the same or higher quality in the future. Essentially come out of Beta - or would that be Alpha? If we're considering 1 as the reason for making "the release" then I would suggest not bothering. We need to be happy forking our resources onto something like a stable branch and the development branch. This means that we need to say which features of the windows we're going to support and draw some immaginary line in the code. Then there's this old argument about trying to hit a moving target. How long before we would have to produce another release which would support the next version of changes that microsoft introduces to their product which gets adapted (DirectX changes pretty often). Now, however, that our dlls are more seperated out, it could mean that we might offer incremental releases of dlls rather than everything at once. That might be a logistical nightmare! We do need to consider the fact that it would mean directing more developer time away from code and into admistrivia functions. > 2. What needs to be done before we can release Wine 1.0? "Emulation" - Come up with a list of apps that we want working. - Also define what having a working app means - how perfect is it? - Be willing to produce some sort of "state of the union" type documention indicating what our future strategy is and what we expect to work in this release. "WineLib" - Come up with a list of products which should compile out of the box (microsoft SDK examples etc) - Major known gotcha's fixed - I guess that might be implied in the previous point. "Other" - All important Corel (and other) fixes existing in our tree. - Having the application database up to date? - Better documentation - everything we have updated - so that we don't get bombed with the same old questions. This is just the dotting the i's and crossing the t's of a real release. > > >I'll start with my personal list: > 1. All apps listed as a '5' work perfectly with Wine > (revising the apps database so that it's accurate > is a fine way to accomplish this, IMO). This would require a fixed list of apps which are required to work (something we don't have yet) and a test cycle type of thing before release. Nothing wrong with either idea. > 2. Many sample applications compile and work with Winelib 'out of > the box' (along the lines of the work that Francois Gouget is doing). Yup. I'm going to, hopefully next week, get around to seeing what Francios has been doing and do the same thing for VWCL as I promissed Todd quite some time ago. > 3. The installation and configuration stuff is cleaner > (I think it's mostly there; I just think it needs a > little spit and polish). How much do we need to do. Most people will get it from some sort of package format anyways. Source could always be considered the developer way of doing things. > 4. The wine server interface is standardized so that > Wine version 1.01 and version 1.1 and version 2.0 > will be able to interoperate with the Wine 1.0 server. I'm not too sure if we want to get into the backwards compatibility type of issues. Comming from an industry where we're fanatical about this sort of stuff, I've seen products that are horrid because this sort of stuff wasn't considered early enough in the design cycle - it was just an after thought. I think that it would be nice, but at the cost of how much work before the release and in future releases? We need to be careful insisting on this one quite yet. If we knew that we had everything in the server that we wanted, I wouldn't have a problem with this (of course I probably wouldn't be coding it). Perhaps start that with version 2.0 when we might be a little more stablized ;) >Thoughts? Comments? > >Jeremy Ciao, Peter Hunnisett [EMAIL PROTECTED]
