... I feel like starting a flamewar, just to get some traffic on this list :)
Speaking of which, I figured I should rattle Alexandre's cage :) 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?
-- Dimi.
... I feel like starting a flamewar, just to get some traffic on this list :)
that's true... we really miss some good ones (licence issues, regression test suite...) ;-)
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?
IMO, what's important behind version numbers isn't the version in itself, but rather: 1] the goal you want to reach 2] the milestones between where you stand and 1]
speaking on 1], it's has been discussed a bit before, but no clear definition has been put up. you can either describe Wine 1.0 in terms of: a) what should Wine 1.0 do? in other words, which apps to you want it to run? b) what should Wine 1.0 be able to do? in other words, the functions you want to be implemented. this functional vs technical controversy isn't new.
Some folks were more interested in the a) approach. It's what Transgaming did (does) with a target on games (as applications). Some others may suggest (O|o)ffice applications (it seems CodeWeavers folks have been busy on this matter lately ;-)
Some other (including Alexandre) were more in favor of the technical approach. This would include finishing the major hurdles. IIRC the discussion at that time, I think most of them have been removed - address space separation: mostly done (even if some USER issues still need to be debugged) - window management rewrite: still in progress - TrueType handling: at least done with Huw latest patches and using XRender (on Xfree >= 4.0.0) Alexandre biggest argument at that time was to stabilize the wineserver protocol definition, so we could upgrade user's side component in a rather stable manner.
Anyway, on a more pragmatic term, let's see what needs to be done: from the a) view: - let most of the installers work. This would require some OLE tweaking. Transgaming has part of it, but isn't ready yet for submission
from the b) view: - stabilize the wineserver protocol (there's still a few pending issues to be added). - put up a decent regression test in place (framework AND tests) - Unicode support (wide, has to be precised a bit) - finish the window management issues - let the documentation be in sync with the code - fix a guzillion bugs
A+
On Mon, 28 Jan 2002, Eric Pouech wrote:
IMO, what's important behind version numbers isn't the version in itself, but rather: 1] the goal you want to reach 2] the milestones between where you stand and 1]
Indeed. But you see, for an outsider, these are all "just details". For most people, version numbers provide a sort of progress bar. (It's true, the info provided by a progress bar is mostly useless, but most people will want that instead of no feedback). It is up to Alexandre to figure out this progress bar, on whatever terms. A version number like 0.98.4 does provide a lot more "warm & fuzzy" (and a little bit more information), than a 020402 version which provides _no_ information whatsoever. In fact, just by looking at such version you can't figure: -- if the project made any progress at all -- how much progress was made (if we assume some did occur) -- the psychological gage of the maintainer on how close we are to some meaningful goal.
-- Dimi.
On 2002.01.28 16:50 Dimitrie O. Paun wrote:
On Mon, 28 Jan 2002, Eric Pouech wrote:
IMO, what's important behind version numbers isn't the version in itself, but rather: 1] the goal you want to reach 2] the milestones between where you stand and 1]
Indeed. But you see, for an outsider, these are all "just details". For most people, version numbers provide a sort of progress bar. (It's true, the info provided by a progress bar is mostly useless, but most people will want that instead of no feedback). It is up to Alexandre to figure out this progress bar, on whatever terms. A version number like 0.98.4 does provide a lot more "warm & fuzzy" (and a little bit more information), than a 020402 version which provides _no_ information whatsoever. In fact, just by looking at such version you can't figure: -- if the project made any progress at all -- how much progress was made (if we assume some did occur) -- the psychological gage of the maintainer on how close we are to some meaningful goal.
There is this wonderful thing called the ChangeLog. There is also the ability to view the wine-cvs mailing list archives and see what has been fixed.
I think that Wine still has a bit to go before we can even consider pre-1.0 releases. As eric said in order to do 0.99.x type releases you need goals/milestones.
I think that we should get all the technical stuff done (i.e. stabilize server protocol, overhaul USER) before 0.99.0.
When the major things have been done then I think we could safely consider wine to be beta software instead of alpha software, at which point I think an 0.99.0 branch of the CVS tree should be made and we should work towards 1.0 from there. The other option is to just leave it in the trunk of CVS-- which for our purposes may be just as well if not better since we'd probably want to concentrate development work on 1.0.
Moving to a 0.99.x version scheme while wine is still alpha is /not/ a good idea.
-Dave
-
David Elliott -
Dimitrie O. Paun -
Eric Pouech