What I would like to ask here is a question I made during a talk, when Hugh Daniel said something like "I don't want to see anything on Freshmeat before 1.0".
[ Home | Articles | Account | People | Projects | FAQ ] 
What I would like to ask here is a question I made during a talk, when Hugh Daniel said something like "I don't want to see anything on Freshmeat before 1.0".
I was at Twente University (The Netherlands) during HAL2001 (Hackers At Large).
I heard some talks by Hugh Daniel (Linux FreeS/WAN Project).
One of those was "The tragedy of software quality in OS/GPL
systems". I don't want to talk about what Daniel said (you will be
able to download from HAL site the video stream or something similar
in the next future, I hope). What I would like to ask here is a
question I made during that talk, when Daniel said something like "I
don't want to see anything on Freshmeat
before 1.0".
The question is:
Is there any standard related to free software development we can
follow numbering our software? In other words, is there a standard
that describes the minimal conditions under which a software can be
numbered, let's say, 0.4?
Something like:
If foo-0.1 then
it has *at least* the following properties (about software and
documentation)
If foo-0.2 then
it has *at least* the following properties (about software and
documentation)
and so on
I think it should be something more specific than GNU Standards.
Any idea?
Having such definitions for "pre-alpha, alpha, beta" etc (i.e. extra words that are not strictly associated with version numbers) isn't good enough?
Not all software progresses monotonically in reliability ...but we really must have monotonically increasing version numbers. Suppose foo-0.6 meets the minimum properties for "0.6" software+documentation and then on the next release backslides to "0.3" for documentation - certainly plausible if there were major UI changes/additions that are not fully documented yet. What number is the project leader to give this release? Or, perhaps, would you forbid him to release it until the documentation has caught up again?
a) The version number is related to the whole software so IMHO it will not
backslide for major UI changes/additions
b) When you say "would you forbid him to release..." please wait... I
don't want to forbid anything! I was wondering what should I do to
match the "Daniel requirments". That's it.
If he says "I don't want to see anything on Freshmeat before 1.0" the
consequence is:
- what should a software have to be 1.0?
and
- what kind of measure of its progress should I use?
It's not trivial to find out, in my opinion
Yes, version numbers are meaningless. If nothing that is not "1.0" should not be announced on fm, that would mean none of the following would show up:
> What would be 1.0-worthy anyway? A *chuckle* "bug-free" product?
Maybe he thinks about a well documented product (code and manual)
Note: this is *NOT* my thinking. I am posting here using Mozilla so I
agree with you but I also think than when a 25-years UNIX experience
hacker like Daniel say something like that... well it shouldn't be so
trivial
Maybe he would say the most part of those software are not scientific
research so we should wait before release because we should focus on
engineering the product.
I hope the HAL staff will release the video/audio stream of his talk ASAP.
"What can be done to improve the state of free software?" is a better question.
I want software that doesn't suck, and I want software that respects my freedom. This comes up often, with solutions ranging from adopting good practices to mentoring new programmers and borrowing from promising software engineering practices. The standard disclaimer, though, will always be that there is no one group that dictates what free software hackers will write, how well they write it, and how anyone else is supposed to identify quality software.
Behavioral solutions (positive peer pressure) seem more likely to work. "Quality" is a Platonic ideal and no one's come up with comprehensive guidelines to measure it. That doesn't stop people from writing feature lists. Here's what I'd expect to see from a "good" piece of free software:
Encouraging people to write free software that doesn't suck is the whole point of my project LinuxQuality.
I don't think the answer is to not release software that is not done yet, but to push for quality every step of the way. On almost every project I've ever been involved with that wasn't under my personal direction, the objective was to push for feature completion and then start fixing bugs. In my view, this is wrong-headed thinking; it promotes the existence of large numbers of bugs you will never be able to fix.
It probably would be good to encourage less experienced developers to join existing projects in a QA and bug-fixing role rather than starting out new projects on their own. I'd like to see more projects completed and fewer 0.1 releases that never get finished.
Read some articles on software quality in Linux. I encourage you to submit articles to me for publication on the site.
Version 1.0 almost always means that the product finally contains all of the features which the developer intended to put in version 1.0. It is as simple as that.
It also usually means that it has ended its alpha and beta testing phases, which gives some indication of stability (i.e. it won't crash if you perform common operations).
The actual version number is unimportant. The problem with versions is that someone might post a project to freshmeat like this:
We are reinventing the Operating System. Current status is that we pop up an unkillable window.
Obviously, they have a grand goal, and have done nothing towards this. Freshmeat is inundated with such "projects". It's noise, really.
I suspect what was really meant was that any project posted would have 90% or more of its core features complete, and it could be expected to perform its tasks without crashing regularly. Gnumeric, Mozilla, and the other <1.0 projects mentioned all have these properties.
It's not exactly on topic, but the Software-Release-Practice-HOWTO discusses similar issues. It doesn't seem to cover when to increase the revision numbers; maybe it should.
I agree with the above that version 1.0 mostly means all intended features (for 1.0) are present. But I think it also means a certain promise of stability and/or backward compatibility, or a promise of more care taken in evolution. Before 1.0 things might change drastically as they evolve toward a stable feature set. After 1.0 any incompatible changes need to be managed carefully (probably cause for a 2.0 designation).
However, all that said, I've been plunking along with ivtools in the sub 1.0 basement for seven years, and can only recall two instances of backward incompatibility: a redefinition of a scripting operator, and a change to a C++ API that required a change anywhere it was invoked in application code (I'm sure there were more). For the most part the recompilation handles all changes to the API (if you take some care). But I never wanted to make that promise until the feature set matured. And now I'm close...
The only thing you leave out that I consider vitally important is error reporting (this is my major release blocker). If people who are new to the program are going to try it out, they're bound to make mistakes and provide invalid input. The program shouldn't just barf on that.
If the user fails to close a brace-pair, they should see "Expected }, found end-of-file at foo.in line 27", not "ParseException" and a stack trace. If the user omits a required line in the input file, they should see "Required line 'fields' not found in foo.in", not a NullPointer (or segmentation fault) as your program attempts to read the contents of that line anyway.
I've been adding this capability to my program for a few weeks now and there's probably a month or more still before I get it fully working (and I'm usually over-optimistic in my estimations). It's *hard* to bolt on a good error reporting mechanism afterwards! If you can get it into your design from the start, you'll save yourself a LOT of work later.
Version numbers are interesting to discuss, but what do you think about
naming of forcked or similar projects?
more/less/most, cc/gcc, calc/xcalc/gcalc/kcalc..........
Could we introduce same - minor and major names?
pager-less-2.3.2.tgz ?
New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!
del.icio.us
Digg
Google bookmark
reddit
Simpy
StumbleUpon
Furl
Newsvine
Technorati
Tailrank