... I feel like starting a flamewar, just to get some traffic on this list :)
Yes!!! Flamewar!!! No retreat!!! No surrender!!!
Speaking of which, I figured I should rattle Alexandre's cage :)
Well, I guess he will have fun with all the outstanding patches. I think he has never had so many. :-)
So here I go:
Wine's been around for 8 (_eight_) years (how time flies)! It is my understanding that we're approaching the 1.0 status. I say, let's change the versioning scheme, just to give the outside world a feeling of progress. Really, I think the current scheme kindda hurts us on a PR level.
We can start with something like 0.90.0. This should give us plenty numbers to the upcoming 1.0, don't you think?
Unfortunetely there won't be any flamewar as far as I'm concerned since don't care very much either way. :-)
But if anybody is intrested in my opinion anyway here goes:
I'm slightly against changing the versioning scheme before 1.0. After 1.0 we probably want to have so sort of different versioning especially since we might release different versions of the DLL:s independently of each other. However I don't think there is much use of having that pre 1.0.
I'm slightly against changing the versioning scheme before 1.0. After 1.0 we probably want to have so sort of different versioning especially since we might release different versions of the DLL:s independently of each other. However I don't think there is much use of having that pre 1.0.
It's funny, I've spent the last two years trying to convince Alexandre we should have an 0.9, but now I think I've reversed my original opinion and think we should stick with our current scheme until 1.0.
Also, I think what's most important about 1.0 is not 1.0 itself, but it is the promise inherent in 1.1 - that 1.1 will do everything 1.0 did, and a little more. To that end, I agree that we should finalize the Wine server protocol, and it sure wouldn't hurt to have a nice regression system in place as well.
Jer
On 28 Jan 2002, Jeremy White wrote:
Also, I think what's most important about 1.0 is not 1.0 itself, but it is the promise inherent in 1.1 - that 1.1 will do everything 1.0 did, and a little more.
Exactly. Until we can be reasonably sure that it will, progress-bar version numbers only serve to make us look incompetent.
To that end, I agree that we should finalize the Wine server protocol, and it sure wouldn't hurt to have a nice regression system in place as well.
Jer
The regression testing we need before 0.9.0 or whatever might make sense. I don't mind if the server protocol changes frequently for now. When it settles down, we can finalize it, subject to change in a later release.
The server version control mechanism works pretty well, and I've only been bit by it a few times.
Lawson
On Mon, 28 Jan 2002, Patrik Stridvall wrote:
Well, I guess he will have fun with all the outstanding patches. I think he has never had so many. :-)
Yeah, I was wondering about that. I have some more in the queue, but I'll for Alexandre to commit whatever I already submitted. (hint, hint :) )
Unfortunetely there won't be any flamewar as far as I'm concerned since don't care very much either way. :-)
You are either with me, or against me!!! No middle of the road will do on this issue :P
-- Dimi.
"Dimitrie O. Paun" dimi@cs.toronto.edu writes:
Yeah, I was wondering about that. I have some more in the queue, but I'll for Alexandre to commit whatever I already submitted. (hint, hint :) )
Do you want me to commit patches, or do you want a flamewar? You can't have both <g>
Seriously, it is planned to have a 0.9 version, but I don't want to use the name for any random version, otherwise it doesn't mean anything more than the current scheme. My plan is to have 0.9 mark the point where all the 1.0 features are in place and all that remains is bug fixing. Then the 0.9.x series will be a progressive code freeze (each release being a little colder than the previous one) converging towards 1.0.
On Mon, 28 Jan 2002, Alexandre Julliard wrote:
Do you want me to commit patches, or do you want a flamewar? You can't have both <g>
But of course I want both! (I'm just like a little kid -- I want my cake and eat it too :))
Seriously, it is planned to have a 0.9 version, but I don't want to use the name for any random version, otherwise it doesn't mean anything more than the current scheme. My plan is to have 0.9 mark the point where all the 1.0 features are in place and all that remains is bug fixing. Then the 0.9.x series will be a progressive code freeze (each release being a little colder than the previous one) converging towards 1.0.
Excellent -- this is exactly what I had in mind. Happy, happy, joy, joy!
BTW, I'm a pedantic bastard sometimes, and one thing that bothers me (and is not that important in the great scheme of things, I agree), is the fact that we haven't completed the directory restructuring yet. I would hope we get that done before 1.0 so we don't have to (1) propagate it for historical reasons, and (2) don't confuse newcomers.
-- Dimi.
On Mon, Jan 28, 2002 at 02:32:48PM -0800, Alexandre Julliard wrote:
anything more than the current scheme. My plan is to have 0.9 mark the point where all the 1.0 features are in place and all that remains is bug fixing. Then the 0.9.x series will be a progressive code freeze
Isn't this slightly against the spirit of the unit tests? (As in "you don't have a feature until you've tested it.)
regards, Jakob Eriksson
Seriously, it is planned to have a 0.9 version,
what would be the content of version 0.9 ? or in other words, what remains to be done before 0.9 ? A+
Eric Pouech eric.pouech@wanadoo.fr writes:
what would be the content of version 0.9 ? or in other words, what remains to be done before 0.9 ?
At this point what remains is inter-process window handling/window management, and dll separation.
"Alexandre" == Alexandre Julliard julliard@winehq.com writes:
Alexandre> Eric Pouech eric.pouech@wanadoo.fr writes: >> what would be the content of version 0.9 ? or in other words, what >> remains to be done before 0.9 ?
Alexandre> At this point what remains is inter-process window Alexandre> handling/window management, and dll separation.
Does this include that a programm started with the desktop option remains in it's own desktop, even if new threads/processes are started? If not, please add to the list.
Bye
Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de writes:
Does this include that a programm started with the desktop option remains in it's own desktop, even if new threads/processes are started?
No, that's in the huge "would be nice to have" category. It's not a mandatory feature for 1.0.
-
Alexandre Julliard -
Dimitrie O. Paun -
Eric Pouech -
Jakob Eriksson -
Jeremy White -
lawson_whitney＠juno.com -
Patrik Stridvall -
Uwe Bonnes