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
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).
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.
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 wrote:
···
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
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).
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 …
This is 99% identical to the rule I follow for RMagick.
A change in X represents a major change. Backwards compatibility not
guaranteed.
A change in Y represents a guaranteed-to-be-compatible upgrade to the
previous release.
A change in Z represents bugfixes.
···
On Sat, 22 May 2004 23:29:58 +0000, Chris Dutton wrote:
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.
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.
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.
Are you implying that all version 3.x projects should blow up or make
things blow up?
···
On Fri, 28 May 2004 22:01:53 +0900, Stefan Schmiedl s@xss.de wrote:
What about people who release software with version numbers like
20040523? Man, that must be pretty advanced
Gavin
···
On Sunday, May 23, 2004, 1:37:26 PM, Hal wrote:
Nicholas Van Weerdenburg wrote:
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.
My typical programs have the x.y format externally, with x indicating
definitive stable releases, and y major changes (bugfixes and changes
that don’t alter features are not documented in external version
numbers). At the same time I keep internal version numbers based on
the date just for my own purpose (it’s easier for me to change a few
numbers in the program than to rename files).
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?
When it comes to 1.0.0, I usually trigger that when most of the
features I want are in, the frequency of new bug reports is low, and
I’m pretty sure the API isn’t going to change a whole lot.
This whole process is different if I have actual customers. Then the
major versions are things that are agreed upon by the business group,
and encompass a feature set. When that feature set is complete, and
the build survives the test group, then it gets tagged as a new major
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.
···
On May 24, 2004, at 11:04 AM, Kirk Haines wrote:
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?
–
“When I am working on a problem I never think about beauty. I only
think about how to solve the problem. But when I have finished, if the
solution is not beautiful, I know it is wrong.”
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.
···
On Tue, 25 May 2004 02:04:23 +0900, Kirk Haines wrote:
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?
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
···
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.
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!
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:
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.
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?).
