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

["Norm Tovey-Walsh ndw@xxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>]

>> 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, butb&if organizations choose bneverb or bin the distant
futureb as the time, thatbs a choice theybre making about the lifetime
cost of their system. Itbs a choice theybre making even if they donbt
realize theybre 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 doesnbt 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
doesnbt 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 thatbs not likely to change. Not because I donbt
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
theybre 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.

Itbs 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 btools vendorb (i.e. bmeb) 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 donbt work.

If an organization ignores a couple of dozen releases over several
years, thatbs 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 whatbs changed. And itbs within the bounds of possibility that there
are changes that werenbt 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 donbt dispute that bIbmb 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@xxxxxxxxxx>
https://nwalsh.com/

> Our repugnance to death increases in proportion to our consciousness of
> having lived in vain.--Hazlitt

[demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]