Minor version standardization?

Posted 22 Aug 2001 at 14:27 UTC by CarloK Share This

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?

devil's advocate-o, posted 22 Aug 2001 at 16:32 UTC by i0lanthe » (Journeyer)

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?

Re: devil's advocate-o, posted 22 Aug 2001 at 17:18 UTC by CarloK » (Journeyer)

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?
- what kind of measure of its progress should I use?

It's not trivial to find out, in my opinion

Version numbers are meaningless, posted 22 Aug 2001 at 17:52 UTC by jschauma » (Observer)

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:

The list could probably be continued ad infinitum, yet these are excellent products that I use on a regular basis. On the other hand, there are plenty of 1.x and higher packages that are pieces of crap.

What would be 1.0-worthy anyway? A *chuckle* "bug-free" product?

Suppose this doctrine was made that no <1.0 package could be announced: what would happen? People would start out with 1.0 instead of 0.1. And the fm staff would have to verify each and every package for the requirements??

IMHO, a product that does something useful, should be released with 0.1 and should be announced as well. Many times I did only continue on a piece of software due to the feedback I have gotten from other people who tried out the software b/c it was on fm. Without the software being used (and many times a piece of software is only used after it has been announced on fm (or similar)) the development process of an Open Source project will halt.

Re: Version numbers are meaningless, posted 22 Aug 2001 at 18:18 UTC by CarloK » (Journeyer)

> 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.

Version Numbers Aren't the Issue, posted 22 Aug 2001 at 18:52 UTC by chromatic » (Master)

"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:

  • easy to install (good build process, sensible packaging if necessary, INSTALL and README files up to date, dependencies clearly marked)
  • specific version information kept up to date (contributors, licensing, known and corrected bugs, new features)
  • runs, at least for the developers, with no crashes. Workarounds are permitted for less serious bugs.
  • ships with enough user-level documentation that the intended users can figure out what to do and how without having to read the source code.
  • ships with documentation for all public APIs. This should include examples.
  • includes contact information, such as developer e-mail addresses, a bug reporting page (if provided), development source code access, mailing list archives, et cetera
  • ships with a comprehensive test suite that users can run to expose and to report bugs. The program should not be released if any tests fail for any developer.
  • should include a roadmap. What features are planned and when, roughly, will they be delivered?
  • does something useful. I don't need an MP3 player, IRC client, or Perl script to update my website. I have several. Other people may, though, so "useful" is intentionally vague.
Any project willing to go to this much trouble has a better chance of being quality software than, say, the first Xlib program I ever wrote. The trick is to encourage people either to join up with projects that have similar standards or to adopt similar standards on their own projects.

Something relevant, posted 23 Aug 2001 at 00:04 UTC by piman » (Journeyer)

The Open Source Directory is a catalog of the sort I believe Mr. Daniel was talking about. Although not all software is post-1.0, and there's nothing to go on that it's complete besides the word of the author, I find that the software there tends to be more featureful, stable, and well-documented than the things on SourceForge and Freshmeat.

Promiting Quality Free Software, posted 23 Aug 2001 at 02:03 UTC by goingware » (Master)

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, posted 23 Aug 2001 at 04:59 UTC by Pseudonym » (Journeyer)

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).

Let's write an IRC client, posted 23 Aug 2001 at 07:44 UTC by jlbec » (Master)

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.

Somewhat related, posted 23 Aug 2001 at 16:00 UTC by mobius » (Master)

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.

1.0 is also a promise of increased concern for backward compatibility, posted 23 Aug 2001 at 17:02 UTC by sej » (Master)

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...

Error reporting, posted 24 Aug 2001 at 15:48 UTC by sab39 » (Master)

chromatic, I like your list. I'm hoping to be making the first release of a tool I'm writing shortly, and I'll definitely be making an effort to meet all the criteria in your list (I don't know if I can attain all of them - in particular, I can't figure out how to make a test suite for some parts of my app - but I'll try).

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.

Forck name standart?, posted 27 Aug 2001 at 20:31 UTC by Malx » (Journeyer)

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 Advogato Features

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!

Share this page