Daniel wrote:
Ron Hunter wrote:
On 8/29/2011 8:16 AM, Daniel wrote:
John wrote:
I use SeaMonkey most of the time and Firefox occasionally. I try never
to use IE.
The web browser and email client are critically important to me, and I
think the majority of users would agree.
Since Firefox and SeaMonkey embarked on their accelerated release
schedule, we've seen several updates incorporating many significant
behavioral changes which are causing grief to many users. Along with
this we are being encouraged to upgrade promptly because that's the
only
way to get the latest security patches. Why the big hurry all of a
sudden?
Changes in program behavior should be fully documented in advance of an
upgrade. Users who prefer the behavior of the old version should be
given the option to retain it. If it ain't broke, don't fix it!
The end user should not be forced to be the guinea pig whose feedback
becomes the quality control for these programs. Please return to the
former more careful release strategy.
I worked as an electrical engineer for Motorola for many years. All too
often, we had products being sold before they were designed and
unrelenting pressure to push them out the door. "There's never time to
do it right, but there's always time to do it over" was the cynical
opinion of many of my colleagues. It seems like the software
industry is
the same way.
Is it really rapid-release??
SeaMonkey 1.0 alpha through to SeaMonkey 1.0.9 - twelve releases over
twenty months.
SeaMonkey 1.1 alpha through to SeaMonkey 1.1.19 - twenty two releases
over forty three months.
SeaMonkey 2.0 alpha through to SeaMonkey to SeaMonkey 2.0.14 - twenty
two releases over thirty months.
Should the question really be *What's the difference??*
There are a lot of differences, but the primary one is that the new
release system includes NOT just bug and security fixes, but NEW
FEATURES. There is also an ongoing User Interface redesign that is
taking place slowly since FF4. I can't see that just how they choose to
number releases affects any aspect of either use, or utility, of a
release. Getting new features, and other 'non-bug/security' fixes to the
user-base as quickly as possible means the FF can remain competitive in
a rather difficult market.
I, for one, think the new system is fantastic, and makes the product
more useful, and more 'current'. What numbers are applied, I will let
others discuss because it doesn't matter to me.
The point, which I apparently failed to make, is that SM updates have
always happened fairly often, so I don't see what the problem with six
weekly updates is??
Daniel,
There should not be any problem with the "weekly updates" as long as the
first in the series contains fully documented changes to how important
user tools and option perform.
Example: When upgrading from SM 2.0 to 2.1 all user tools and options
that have been improved from the previous version need to be fully
documented within the application Help Files. Major security fixes need
to be fully documented where those fixes may change the behavior over
the older version.
When making a minor version change (2.0.1 to 2.0.2) or (2.2.1 to 2.2.2)
for security patches those changes must not change any user tools or
operations. If a security patch is required that will affect user
options then a new version level needs to be created with full
documentation.
Full documentation does not mean disclosing the code base in question,
but dose mean how the changes will affect user experience with the new
upgrade.
Failure to perform these simple tasks will drive more users back to MS
Internet Explorer and Outlook.
Conclusion: The number of security patches is very important to keep our
applications secure from the nasty world of Hackers and Crackers trying
to infect our computers. At the same time the new and improved
updates/upgrades must document the changes and how they may affect user
experience.
I don't mind having one, two, or three security upgrades a week if those
upgrades do not affect how I use SM, and if they may affect my use of SM
how do the changes affect how I use SM.
Michael G
_______________________________________________
support-seamonkey mailing list
[email protected]
https://lists.mozilla.org/listinfo/support-seamonkey
