.
Yes, I completely agree.
This stable was required as soon as possible to solve once for all the current confusion that occurred to users trying out the newer editions of LiveXP and VistaPE that required using 075 beta >5 while 074 was still the stable edition.
Things were getting a bit confusing.
If the updates are done on scheduled basis then I would hope that there isn't much need for an RC since few things should change from one stable to the next.
Perhaps we can send an early message to .script developers some days before the release so that there is a chance of a preview by the experts that allows expressing their thoughts about things missing to be corrected.
Would this be a good idea?
Yep, the idea of solving confusion, is to actually reduce it, NOT augmenting it releasing a stable that has been fixed at least twice in a few days.
The "wrong" attitude, if I may
, was to confuse "beta-testers" and "beta-releases" with "everyone" and "nightbuilds" or ALPHA testing.
Moreover I see that sometimes "bugs reports" and "features" are mixed.
I know I'll be probably be flamed for this, but I see a "pattern":
- a bug is reported - often a very minor one
- psc, willing to help, fixes it as soon as he can - sometimes this, of course unwantingly - creates a new bug
- another user posts about the bug he got in the supposedly fixed "nightbuild", unpropeerly called beta (as it should be called ALPHA-ALPHA)
- psc again tries to fix the "other" reported bug and creates a new "beta"
- some user asks for or suggests a (usually very interesting) feature
- psc again introduces it as soon as he can
- a number of users, to avoid keeping track of the "which is the latest build", stick to the last "known to be working for them" version, waiting for the next "stable"
- only when the next "stable" is out, they test it and then a number of bugs that were overlooked due to scarce testing in the "beta" stage, which as said was actually an ALPHA one come out
- psc is "forced" to fix the "stable", thus making it a "non-stable" and actually adding to the confusion
In other words, it is my opinion that an improper procedure takes place and that
paradoxically the incredible amount of time and willingness that peter (and other people) puts into development and bug reporting
actually increases the confusion.
The "proper" way in projects (not necessarily software ones, same principles apply to other fields as well) should be, more or less structured as follows:
- establish a "roadmap" AND a "timetable" for next "stable" release and intermediate alpha's beta's and RC's (of course NOT mandatory, but reasonable and "possible")
- the "roadmap" declares in advance which features are wanted/needed and will be introduced
- the timetable describes when they will be implemented
- a term is also given for the "freeze" and the "call for papers" (i.e. deadline for feature requests or contributions)
- NO "new" feature is added if not within the accepted roadmap, contributions and requested features are "shifted" to NEXT iteration
- once the "freeze" has taken place, and ALPHA has already been tested by the very restrict circle of developers, a "beta" is given to a still restricted group, the "beta testers"
- once bugs reports from these people ONLY are fixed, a "Release Candidate" is published, and the "general public" is called to do some more testing, the RC has as well a term for submitting bugs
- ONLY reported bugs specific to the RC are fixed, and a new RC is issued and a new term is given for bugs report
- when there are no more bugs reported within the RC term, latest RC without any change is released as "stable" and the process loops back from start
jaclaz
