Quote:Original post by TheBuzzSaw Let's pick one example: DOSBOX. In my opinion, DOSBOX should have hit version 1.0 a long time ago. It is stable, feature-rich, and dependable. As of right now, it shows up as version 0.74. When will version 1.00 come out? Will it arrive 26 releases later?
so its still a bit to go, the fact that its good enough for most users or even good enough for commercial use (some steam games and most games on gog.com rely on it) doesn't mean its finished, technically its not even in beta yet since its not feature complete.
[size="1"]I don't suffer from insanity, I'm enjoying every minute of it.
The voices in my head may not be real, but they have some good ideas!
In the couple of libraries I've done I've decided up front what (inital) feature set I want and then once that feature set, or a compromise one, is completed and stable I'll label it '1.0'. After that bug fixes increment to say 1.0.1 as required, minor feature additions adjust to 1.1.x as required.
At which point I'll look again at the feature sets, decide if I need to break compatibility or not, and if so begin work on the next major version which will have a new set of features and will become, in time, version 2.0.
Very few things use hard numbers for versioning. Hardware, for example, doesn't. Chips are labeled based on production batches, so same chip will have many versions in production.
If faults are detected, the first thing manufacturers do is try to examine if it's the problem with entire batch, or just a handful of chips. Sometimes, manufacturers are changed between batches, or the process is adjusted, so what is labeled as same chip comes from different design and different vendor.
The only thing that matters from QA perspective is the interface. Those are the ones that break things. In enterprise setting, especially Java, versions are a huge thing. The entire development process is centered around hard versions, since each interface breaking change ripples across documentation, training, support, life-cycle management, distribution, upgrade plans, .... Windows is an example of this type of support - advancing versions is a huge process.
Web apps are mostly services. Hard versions there don't make sense, especially in presence of split testing or other metrics. Any typical consumer-facing web service will be running many versions simultaneously, and relation between them is not linear or sequential. There will be multiple versions of same branch, discardable A/B testing branches, prototype functionality, random tests.
When working with git or Hg, there are no versions at all, just a version ID which is an opaque number.
The need for versions is strongly correlated with number of passive users. In most cases in web space, few users are passive - most libraries will be tweaked and tuned. Contrary to that, Joomla and similar frameworks are hard-versioned, since they provide support, hosting as well as templating and design services - but few will tweak the core code.
Software released on printed media starts at version 1. Flash games or similar are not hard versioned, since they are continuously updated.
Silver bullets and all that - there is more than one way.
Quote:Original post by SimonForsman Does it really matter though ?
It does, because it's often difficult to predict the long-term viability of an open-source project. Sourceforge is littered with abandoned 0.1s, projects that the author was excited about but not invested in. It's easy to make an 0.1 project. It doesn't commit you to anything. Saying "1.0" is ballsy; it's just daring people to complain that it isn't ready for prime-time. It's far from a perfect predictor, of course, but it is a decent suggestion that the author is confident of the project, and has done at least a little bit of thinking about its development plan.
EDIT: I just went back and looked at the front page of FreshMeat.NET from early 2006. Of the first five projects with >1.0 versions, four have been updated in the last year or so. Of the first five projects with <1.0 versions, only one has.
so its still a bit to go, the fact that its good enough for most users or even good enough for commercial use (some steam games and most games on gog.com rely on it) doesn't mean its finished, technically its not even in beta yet since its not feature complete.
This is a valid observation. It's just one I would disagree with if I were a part of the DOSBOX team. To me, version 1.0 would be that it is stable (as in, the program at least runs fine without crashing) and usable (I can play my initial batch of game tests). Then, I would put that list you linked as the goals for version 2.0.
Regardless of incomplete components, DOSBOX just works. I have had no problems running any of my old DOS games (and I have quite a few). To me, that is a classy 1.0 project. The 0.74 generically screams "may or may not work; try it out if you are a brave developer" to me. I understand that others may see it differently, but it just kills me that such programs label themselves as so "incomplete".
Amateurs practice until they do it right.Professionals practice until they never do it wrong.
Quote:Original post by TheBuzzSaw Regardless of incomplete components, DOSBOX just works. I have had no problems running any of my old DOS games (and I have quite a few). To me, that is a classy 1.0 project. The 0.74 generically screams "may or may not work; try it out if you are a brave developer" to me. I understand that others may see it differently, but it just kills me that such programs label themselves as so "incomplete".
http://www.dosbox.com/comp_list.php?letter=a
it doesn't "just work" , plenty of games are broken and won't even run, and quite a number just barely run.
For me thats not acceptable for a 1.0 product.
[size="1"]I don't suffer from insanity, I'm enjoying every minute of it.
The voices in my head may not be real, but they have some good ideas!
Quote:Original post by SimonForsman http://www.dosbox.com/comp_list.php?letter=a
it doesn't "just work" , plenty of games are broken and won't even run, and quite a number just barely run.
For me thats not acceptable for a 1.0 product.
Have you used DOSBox? Sure, there is a substantial list of obscure titles that don't quite run yet, but that could be for any number of reasons. I've had old games stop working even while running natively in the real DOS. Maybe some of those games have horribly unredeemable bugs/glitches. As far as DOSBox is concerned, I don't think it would EVER reach version 1.0 according to your standard. Again, I don't feel that version 1.0 means "perfect". DOSBox works great.
Are you familiar with WINE? That does not run all Windows apps flawlessly. Is that project not deserving of its current 1.0 version number?
Amateurs practice until they do it right.Professionals practice until they never do it wrong.
Quote:Original post by SimonForsman http://www.dosbox.com/comp_list.php?letter=a
it doesn't "just work" , plenty of games are broken and won't even run, and quite a number just barely run.
For me thats not acceptable for a 1.0 product.
Have you used DOSBox? Sure, there is a substantial list of obscure titles that don't quite run yet, but that could be for any number of reasons. I've had old games stop working even while running natively in the real DOS. Maybe some of those games have horribly unredeemable bugs/glitches. As far as DOSBox is concerned, I don't think it would EVER reach version 1.0 according to your standard. Again, I don't feel that version 1.0 means "perfect". DOSBox works great.
Are you familiar with WINE? That does not run all Windows apps flawlessly. Is that project not deserving of its current 1.0 version number?
Yes i'm using both frequently, neither should be 1.0, yet.
Wine is very far from finished, the fact that its useful doesn't change that fact that its not finished, lots of components are broken or only partially implemented to get one or two applications to run, DOSBox on the other hand is close to finished and i wouldn't be surprised if we saw it take a decent jump in the version number at some point in the near future.
If they want to slap a 1.0 number on it they should set a sensible milestone that marks it as finished in atleast one aspect. (Getting 4 arbitrarily chosen applications (Which is what the Wine team did when they wanted to get 1.0 out) to run isn't, it would be as if Microsoft considered Windows Vista ready for release when it ran Office and World of Warcraft, support for other applications can be added in Windows 7 right ?)
[size="1"]I don't suffer from insanity, I'm enjoying every minute of it.
The voices in my head may not be real, but they have some good ideas!
Given I haven't done a public release in years, but if I were to release something these days I don't think I'd bother with the Major.Minor.Build versioning scheme, I'd probably just use the source control revision number of the most recent stable build. That way at least you have a known watermark for where your release was in your versioning system, so you can easily gauge what's been fixed/added since the last revision.
The numbers are equally cryptic to users anyway. 1.3.476 gives the consumer just as much information as r7489, which is pretty much nothing other that 'this version is more recent that the other one'. Major revisions for marketing reasons should probably just be limited to the product name; SuperAwesomePhotoeditor 5 and the like.
I think the reason for it is that they know what they want in 1.0, and being hobbbyist project, they don't have the resource to do it all, very fast.
Of course, since they don't look into profit and return, what they want in 1.0, could be, what commercial app want in 2.0, or even 4.0.
We can look at Dosbox.
IF (I repeat, if, I'm being theorytical here) I'm a dosbox developer, and I have lot's of programmers to feed, I would target DosBox 1.0 as 486 emulator with VGA & Sound Blaster support, and MARKET it as so. After all, that's what most people (and company) need for the moment anyway. CGA can come later, other less popular sound card can come later, UNDOCUMENTED system tricks can come later (things that some games prefer to use, and lot of demo coders use).
As I went for 2.0 (and get new customers, and upgrade cash from current customer) I would add support for EGA, and 386, and maybe Roland sound card.
As I went for 4.0 and maybe all those bars at current Dosbox page is 100% (easier if you paid experienced people to do this and doing it at real work hour) you could just:
a) create new product. b) fire most of current developer and hold only skeleton crew for bug fixes. Not fire as in "I don't need you now" kind of things, but when you're 2.5, and you know where the company is heading, you knew there would be no more upgrades after 4.0 (what else to add?), and how much new customer can you get? (all those that want to have such emulator, would have bought it since 1.0 or 2.0).
Business have to look into this kind of things, some hobby open source software don't. Of course, it's not right to just slap 1.0 and release things (ET and Battlecruiser 3000 AD).
Of course, there are also open source app that just doesn't deserve 1.0, usually when it have ambitious developer who want to add everything including kitchen sink, and usually add new thing when it's THE RAGE at the moment, stop working on it when it just works (forget about all the bugs and instability, etc). You know this when it has gajilions of features, at 25% each of it. Want to be good enough to make Quake 6, but hard to use and unstable enough to even develop tetris with it (my grudge at 2000-2007 open souce game engines (some of it, that is).
I guess when you just don't care about the money and people to feed, that 1.0 is not important enough I guess.
