Is that right?
yes,
Guy Decoux
The user has to read the documentation regardless of the version number.
Version numbers are subjective. With the iterations of certain features
that Iowa has gone through, I could easily have it numbered at 2.x now.
That doesn't tell you any more than 0.2.x does, though. It may give you a
different impression, but you still don't know anything until you do your
research.
One of the reasons that I am reticent to go to a version 1.0 yet is, in
fact, not related to the software at all. Rather, it's the documentation.
My documentation needs to be to the point where at least most of the main
things that a person should know to successfully use the software is laid
out in an accessible manner. I've been answering questions from one fellow
for about a week now who is experimenting with Iowa that are illustrating to
me a number places where my documentation is obviously lacking. To my mind,
the availability of sufficient documentation is perhaps an even more
important aspect of labeling something version 1.0 than the software feature
set.
It could be version 9.3.7 or version 0.0.5, but if there isn't sufficient
documentation for one to do due diligence research, the version number is
not particularly important except as a counter.
Kirk Haines
···
On Mon, 12 Jul 2004 00:02:27 +0900, Neil Stevens wrote
That's why version numbers less than one are meaningless. If the
user has to guess and read the documentation anyway then the version
number conveys no information to the user.
Kirk Haines wrote:
It could be version 9.3.7 or version 0.0.5, but if there isn't sufficient
documentation for one to do due diligence research, the version number is
not particularly important except as a counter.
Then how about using dates as versions? Call the release made tomorrow
20040712.
That won't drive off users who are going to make the reasonable assumption
that anything below 1.1 can't be trusted for real work, it'll let you
distinguish one release from another, and everyone wins.
···
--
Neil Stevens - neil @hakubi.us
"The world is a dangerous place to live; not because of the people who
are evil, but because of the people who don't do anything about it."
-- Albert Einstein(?)
It's not a reasonable assumption. The points made against that
assumption by various people carry more logic than your mere
assertion.
Using dates betrays any notion of a planned release schedule, so it's
not a win-win situation.
Gavin
···
On Monday, July 12, 2004, 1:57:27 AM, Neil wrote:
Kirk Haines wrote:
It could be version 9.3.7 or version 0.0.5, but if there isn't sufficient
documentation for one to do due diligence research, the version number is
not particularly important except as a counter.
Then how about using dates as versions? Call the release made tomorrow
20040712.
That won't drive off users who are going to make the reasonable assumption
that anything below 1.1 can't be trusted for real work, it'll let you
distinguish one release from another, and everyone wins.
Gavin Sinclair wrote:
Then how about using dates as versions? Call the release made tomorrow
20040712.That won't drive off users who are going to make the reasonable assumption
that anything below 1.1 can't be trusted for real work, it'll let you
distinguish one release from another, and everyone wins.It's not a reasonable assumption. The points made against that
assumption by various people carry more logic than your mere
assertion.Using dates betrays any notion of a planned release schedule, so it's
not a win-win situation.
Two apps, both at version x.y.z, may be in very different states of reliability and feature creep.
But for any given release if you are using Foo 0.2.0, and see that version 0.2.1 is out, it should mean something different than if 0.3.0 comes out.
Dates do not allow one to indicate if a release is major or minor.
The version numbers of a given app should at least serve as some sort of code/feature "distance" marker, though the meaning will vary among applications.
If there is any sort of consensus among Rubyists on release number guidelines then perhaps some kind soul may offer to write them up and put them on rubygarden.
Can anyone tell me if REXML cn bepersuaded to generate using double quotes rather than single quotes
ie.
<div class="hello">
rather than
<div class='hello'>
I am also strugling to persuade REXML not give me attributes with normalized values.
In the following
<a href="javascript:window.open('http:// .......... ">....</a>
I get
<a href="javascript:window.open('http:// .......... ">....</a>
thanks in advance for any help
Keith
Since RubyGems is concerned with version numbers, Jim Weirich has
written a RationalVersioningPolicy on the RubyGems wiki at
http://rubygems.rubyforge.org.
According to that policy, every time a backwards-incompatibile API
change occurs, the major version number gets bumped. I guess there's
an implicit caveat for very early versions of a project, otherwise
we'd have version numbers like 15.0.1 frequently. Jim?
Cheers,
Gavin
···
On Monday, July 12, 2004, 2:23:22 AM, James wrote:
Gavin Sinclair wrote:
Then how about using dates as versions? Call the release made tomorrow
20040712.That won't drive off users who are going to make the reasonable assumption
that anything below 1.1 can't be trusted for real work, it'll let you
distinguish one release from another, and everyone wins.It's not a reasonable assumption. The points made against that
assumption by various people carry more logic than your mere
assertion.Using dates betrays any notion of a planned release schedule, so it's
not a win-win situation.
Two apps, both at version x.y.z, may be in very different states of
reliability and feature creep.
But for any given release if you are using Foo 0.2.0, and see that
version 0.2.1 is out, it should mean something different than if 0.3.0
comes out.
Dates do not allow one to indicate if a release is major or minor.
The version numbers of a given app should at least serve as some sort of
code/feature "distance" marker, though the meaning will vary among
applications.
If there is any sort of consensus among Rubyists on release number
guidelines then perhaps some kind soul may offer to write them up and
put them on rubygarden.
Keith P Hodges <keith_hodges@yahoo.co.uk> wrote in message news:<a0611040bbd1749936a3f@[192.168.0.100]>...
Can anyone tell me if REXML cn bepersuaded to generate using double
quotes rather than single quotes
Nope. You can submit a feature request, though, at:
http://www.germane-software.com/cgi-bin/roundup/rexml
and I'll add it when I get a chance. This week is pretty busy and I
haven't had any time to do any REXML work, but I should have some time
to work on it this weekend.
If you need to replace quotes with apostrophes, hack the
Attribute#to_string method in rexml/attribute.rb and just replace them
yourself. It isn't an ideal solution, but it should suffice for a
short-term fix.
I am also strugling to persuade REXML not give me attributes with
normalized values.
They should be normalized for proper XML. REXML does not generate
HTML, which is an SGML language. For instance, <br>s in HTML are not
closed. There's a whole section in XSL that talks about how XML
should be re-formatted to be "proper" HTML.
In the following
....
I get
<a href="javascript:window.open('http:// .......... ">....</a>
REXML always uses apostrophes, so this can't really be what you're
getting. In any case, there isn't a way to turn off normalization in
REXML attributes at the moment.
This shouldn't be a problem with modern browsers; I think even IE, as
non-conformant as it is, accepts entities in attributes.
--- SER