One more idea. What about creating a field on boltwire.com to test new
releases?

We would create pages for all kind of things like nested everything,
advanced forms, messages, snippets etc. This would allow to easily
check if a release is more or less stable. Each of us uses different
features of BoltWire. So if there is a bug in some less commonly used
part, it will take until user x updates to identify it -- which might
be 2 hours or 2 months.

A testing field would allow systematic review of BoltWire's features
(or bugs). I am not sure how far the testing could even be automated.
For example, if you have a form that should give a certain message if
bug free, you could compare the actual output with the expected and
display some red warning or green OK.

This would guarantee to a very high degree that you can expect a
release that has been tested to fulfill BoltWire's advertised features
and work as expected. And if you as a user take care that the features
you use are part of the testing field, you can be quite sure that an
update is safe.

Last thought on this. We generate so much valuable input here which is
not used. If there is some tricky code that nobody considered during
development and therefore nobody noticed that it might break, then
this code should be conserved for future testing. A teacher of mine
once said: Stupidity is when you make the same mistake twice.

Regards, Markus

On 8 Okt., 10:31, Hans <[email protected]> wrote:
> You make some very good points, Kevin.
>
> My question is , how relevant is this to BW?
>
> I think there is a general problem in determining when  a BW release
> is "stable".
>
> It happened many times that Dan announced a stable or fairly stable
> release, only to discover after a few days that it broke some things
> which worked before, and it needed some fixing.
>
> The consolidation phase  for a stable release you mention, where bugs
> get fixed, but no new features added, no major code is rewritten, is
> not happening for BW.
>
> I think this may be so because the user base is fairly small, the ones
> active on the list are all working with "cutting edge" releases, and
> Dan is really only interested in pushing BW forward fast, and does not
> want to bother with "consolidation".
>
> This makes for exciting development, but not good for finding stability.
>
> Dan's suggestion for a new naming convention helps to identify a
> release as "more stable", but the challenge is still there to proof
> its stability, and I am afraid no one is interested to do so, as
> everyone wants to go with the cutting edge, as that is the only
> development front there is (and nobody to blame for that).
>
> Going with Dan's suggestion and renaming 3.18 to 3.2, to mark it as a
> "stable release", I wonder when it is appropriate? Two days of no bug
> reports seems very short to me. But if Dan waits longer, say two
> weeks, to judge the stability of 3.18, he meanwhile has already
> produced 3.19 to 3.25! And if some bug is reported from 3.18, it won't
> get fixed, but the user will be asked to try the latest, say 3.22! So
> we won't see a consolidation. Instead, we see a continuous "cutting
> edge" development, which may be be called continuous beta releases,
> from the develoment cycle model Kevin mentioned.
>
> I am afraid someone  needs to do the consolidation work, and it is not
> Dan. He is not even that interested in updating documentation (a big
> part of the consolidation work) and calls on the community for that.
>
> Thinking about the version numbering:
> It may be better not to rename 3.18 to 3.2 and dive into new releases 3.2.xx.
> It may be better to keep 3.18 and start a new phase (with new features
> added etc) with 3.21 then 3.2.2 etc, a new 3.2.xx phase, and mark the
> 3.18 as "fairly stable" at some point (when?).
>
> anyway, just some thoughts....
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"BoltWire" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/boltwire?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to