[SemiOT] Concerning version numbers...

[Hal Fulton]

A few people in recent weeks have been bemoaning the fact that software
projects (in the RAA and elsewhere) often consist of "mostly leading
zeroes."

I have been thinking about this. Some very valid points have been made.

But at the same time, it seems to me that many projects nowadays are
1) following the "release often" model and 2) hoping to attract
contributors and collaborators.

And these two issues are probably linked.

In any case, if a release is made, say, every ten days -- I think it
makes sense to have leading zeroes. The alternative, it seems to me,
is that in a year we are all using Version 47.5 of the software.

That might be preferable to some, but I like to think of version 1.0
as being of at least post-beta quality (although we all know it really
starts being useful at 1.1).

Just my opinion.


Hal

 

[Chris Dutton]

Seems to me that a sensible model is:

x.y.z

X is a truly major, ground-shaking architectural change, quite possibly
breaking backwards compatibility. Y is a significant feature addition.
Z is a minor release: a bugfix, or performance enhancement, for instance.

 

[Tim Hunter]

Seems to me that a sensible model is:

x.y.z

X is a truly major, ground-shaking architectural change, quite possibly
breaking backwards compatibility. Y is a significant feature addition.
Z is a minor release: a bugfix, or performance enhancement, for
instance.

This is 99% identical to the rule I follow for RMagick.

1. A change in X represents a major change. Backwards compatibility not
guaranteed.

2. A change in Y represents a guaranteed-to-be-compatible upgrade to the
previous release.

3. A change in Z represents bugfixes.

 

[Nicholas Van Weerdenburg]

Trailing decimal places would serve the same purpose.

e.g. 0.5.1.01

This is really no different then commercial software development with
build numbers and regular internal test builds.

I'm not sure about the second point- I'm more inclined to contribute to
something I'm using, whether it's 0.5 or 3.1. Do Perl or Python history
offer some insight into this?

Nick

 

[Hal Fulton]

Trailing decimal places would serve the same purpose.

e.g. 0.5.1.01

This is really no different then commercial software development with
build numbers and regular internal test builds.

I'm not sure about the second point- I'm more inclined to contribute to
something I'm using, whether it's 0.5 or 3.1. Do Perl or Python history
offer some insight into this?

That wasn't the point I was trying to make. The point was that by making
the development public, by taking a "release often" approach, we have
very frequent releases and use up a lot of numbers.

I guess I was just making a counter-argument to those who say there
should only be two or three releases, and nothing before 0.9 should
see the light of day.



Hal

 

[Gavin Sinclair]

That wasn't the point I was trying to make. The point was that by making
the development public, by taking a "release often" approach, we have
very frequent releases and use up a lot of numbers.

I guess I was just making a counter-argument to those who say there
should only be two or three releases, and nothing before 0.9 should
see the light of day.

What about people who release software with version numbers like
20040523? Man, *that* must be pretty advanced

Gavin

 

[Kirk Haines]

This is an interesting discussion, as it's something that I have vacillated
on for years. Generally, I think that the x.y.z public version numbering
scheme is a good one, oftentimes combined with using something like 20040524
after all of that to help keep track of minor changes and internal items.

One thing that I'm trying to figure out right now, though, is when to make a
jump from 0.y.z to 1.0.0. When is a piece of software stable enough to no
longer be a 0.y.z version? Is this a completely subjective judgement, or do
you all think there are some objective criteria that can be applied to guide
the decision?


Kirk Haines

 

[Gavin Kistner]

One thing that I'm trying to figure out right now, though, is when to
make a
jump from 0.y.z to 1.0.0. When is a piece of software stable enough
to no
longer be a 0.y.z version?

I would say it's not a stability issue, it's a (stable) feature issue.

0.9 is "I haven't yet added all the features I think should exist for
the initial 'done' release."

1.0 is "Sure, there are more features that would be nice to add, but
all the core features are in there, and I have 1.1 and 1.2 for those,
and 2.0 for the really big rewrites or major changes."

This determination (which I'm sure is not my own) is why all the 0.x
versions baffle me...products that have been (or certainly appear to
have been) feature-complete for months (or years) shouldn't be 0.x. If
it's taking forever to reach 1.0, perhaps the feature list needs to be
re-examined. 1.0 isn't the penultimate world-dominating final release,
it's the initial major release. Just because you thought of a neat
feature during initial development doesn't mean that it needs to be
implemented for 1.0.

 

[Kirk Haines]

On Tue, 25 May 2004 04:43:57 +0900, Gavin Kistner wrote

I would say it's not a stability issue, it's a (stable) feature issue.

0.9 is "I haven't yet added all the features I think should exist
for the initial 'done' release."

1.0 is "Sure, there are more features that would be nice to add, but
all the core features are in there, and I have 1.1 and 1.2 for those,
and 2.0 for the really big rewrites or major changes."

This determination (which I'm sure is not my own) is why all the 0.x
versions baffle me...products that have been (or certainly appear to
have been) feature-complete for months (or years) shouldn't be 0.x.
If it's taking forever to reach 1.0, perhaps the feature list needs
to be re-examined. 1.0 isn't the penultimate world-dominating final
release, it's the initial major release. Just because you thought of
a neat feature during initial development doesn't mean that it needs
to be implemented for 1.0.

Thanks. That's a good way of putting it. This is something that I just
never really got my head around before. Maybe in part it is because in the
past almost all of the software and the libraries that I wrote were in-house
products that stayed in house, so versions were also internal and I didn't
really have to think about it. Now that I'm trying to be a lot more open
with the software tools that I use to get my work done, though, I've found
this topic to be the most difficult simple thing I've had to think about in
a while.

I guess the next release of Iowa will be 1.0. Thanks for helping me sort
this out in my head!


Kirk Haines

 

[Hal Fulton]

Thanks. That's a good way of putting it. This is something that I just
never really got my head around before. Maybe in part it is because in the
past almost all of the software and the libraries that I wrote were in-house
products that stayed in house, so versions were also internal and I didn't
really have to think about it. Now that I'm trying to be a lot more open
with the software tools that I use to get my work done, though, I've found
this topic to be the most difficult simple thing I've had to think about in
a while.

I guess the next release of Iowa will be 1.0. Thanks for helping me sort
this out in my head!

Likewise. This makes sense to me. I guess I perceived that some people
were addressing the opposite issue: Should a non-feature-complete
package be made public at all?

To sum up my own thoughts on the matter:

1. A usable, relatively feature-complete, post-beta piece of software
can be version 1.0. If there is MAJOR missing function, or MAJOR bugs,
maybe it shouldn't be.

2. It's OK to release things that are not feature-complete, especially
if you are soliciting aid in working on the project. This is consonant
with the "release often" policy for open source projects (or did it
originate in the XP community?).


Hal

 

[Tim Hunter]

One thing that I'm trying to figure out right now, though, is when to make
a jump from 0.y.z to 1.0.0. When is a piece of software stable enough to
no longer be a 0.y.z version? Is this a completely subjective judgement,
or do you all think there are some objective criteria that can be applied
to guide the decision?

I think of 1.0.0 as a promise to your users. You're promising that your
code is of _production_ quality. That is, if they d/l your code they will
find that it has enough features to be useful, is robust, and is stable.

I would also say that 1.0.0 code should have sufficient documentation to
be useful _without_ having to read the source code.

 

[Stefan Schmiedl]

A few people in recent weeks have been bemoaning the fact that software
projects (in the RAA and elsewhere) often consist of "mostly leading
zeroes."

Ooooh, I was one of them

FWIW, here is part of a release plan for a software project I'm working
on: Release number are assigned only unwillingly and for PR-reasons,
because things get shuffled around alot.

The Wheel - look ma, it moves
14 items, 9 done, 5 to go
The Beetle - a stable workhorse
currently 5 items, 0 done
The Mercedes - a really comfortable environment
currently 4 items, 0 done
The Bond Car - gizmos galore
currently 1 item, 0 done

If you want to translate it to conventional numbering:
Wheel = 0.x
Beetle = 1.x
Mercedes = 2.x
Bond = 3.x

Just in case you're wondering, I'm talking about the classic Volkswagen
Beetle built in the 50's and 60's and not the modernized second edition
where you actually had fancy stuff like working heating system etc

The advantage of this approach is that discussions about which features
go in what release become quite rare. Everybody knows what to expect
of buttons in a Bond car ...

s.