xsl-list
[Top] [All Lists]

Re: [xsl] [Ann] Oxygen XML Editor version 23 release

2020-11-23 13:11:59
So it's not a question of like or dislike, fun or no fun, it's a
question of economics, of minimising the lifetime costs of your
system. Of course, the calculations will come out differently for
different projects.

I agree. But it is also a question of timing. The time for an
organization to upgrade should be up to the users, not to the vendors
of their tools.

Well, yes, but…if organizations choose “never” or “in the distant
future” as the time, that’s a choice they’re making about the lifetime
cost of their system. It’s a choice they’re making even if they don’t
realize they’re making it, unfortunately.

The time and energy and resource constraints that motivate users to make
(or not make) choices apply equally to the tool vendors and the book
authors and the consultants and Uncle Tom Cobbley and all.

In addition, software doesn’t exist in a vacuum. We might once upon a
time have created statically linked executable files that could in
principle run as long as the hardware architecture existed. But today,
most software relies on dynamically linked libraries and an ecosystem
around it that moves much faster than it used to. Heck, even hardware
moves faster than it used to. For all I know, IBM still supports the 360
architecture I was familiar with almost 40 years ago, but Apple sure
doesn’t support the Motorola architecture anymore.

Consider XProc, as a randomly chosen example :-). Among the
organizations using XProc, there will undoubtedly be some who are
perfectly happy with 1.0 and will have no short-term motivation to
upgrade to 3.0.
 
I am single handedly and somewhat desperately trying to get my 3.0
implementation finished.

I have not been very responsive of late to bug reports on the 1.0
implementation and that’s not likely to change. Not because I don’t
care, not because I want to force organizations to change tools that
work for them, but because *I also* have to make choices about where to
invest time.

XML Calabash relies on Java libraries that are moving forward. Sooner or
later the vendors of *those* libraries will have abandoned the versions
that my 1.x implementation uses. And the new libraries will have
incompatible APIs (for reasons both good and bad, but inevitably).

Consider the following hypothetical scenario: two years from now, the IT
department at Acme Corporation runs a routine scan of the software that
they’re using. They discover that the some team is using XML Calabash
1.x that relies on FictitiousComponent version 3.4 which has a known
security vulnerability. They demand that the team stop using it.

It’s unlikely that my 1.x implementation will compile against the then
current FictitiousComponent, version 18.2 (assuming the component still
exists) and, even if it does, it probably requires OtherComponent 9.7
which is incompatible with 6.2 which is used elsewhere in XML Calabash
1.x.

So now the “tools vendor” (i.e. “me”) is telling them they must upgrade
to 3.0 which makes me the bad guy. But what practical choices do I have?

AND, there are things tool vendors can to do make updating easier. For
example, providing guidance on how to "fix" things that "break" in
such an upgrade. If a capability is removed from a product, even if

This is true, of course, but I think there are also aspects of mutual
responsibility here as well. Continuing with my XML Calabash example,
suppose some organization has been using version 1.0.7 for a few years
and now you want to upgrade to 1.22 and they find that there are things
that don’t work.

If an organization ignores a couple of dozen releases over several
years, that’s a choice. And one consequence of that choice is that they
may have to read the release notes for the last dozen releases to figure
out what’s changed. And it’s within the bounds of possibility that there
are changes that weren’t sufficiently documented, because that happens
and because it may be that the problems observed are a consequence of a
number of related changes each of which might have been easy to resolve
but that now present in a novel way.

Again, I don’t dispute that “I’m” the bad guy here, there should be
better and more comprehensive release notes. There should be better and
more comprehensive testing. I am getting better at some of those things,
but there are only so many hours in the day.

                                        Be seeing you,
                                          norm

--
Norman Tovey-Walsh <ndw(_at_)nwalsh(_dot_)com>
https://nwalsh.com/

Our repugnance to death increases in proportion to our consciousness of
having lived in vain.--Hazlitt
--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--

Attachment: signature.asc
Description: PGP signature

<Prev in Thread] Current Thread [Next in Thread>