We all understand in an ideal (and also little changing world), we'd have very wide prereq ranges, such as [1.0.0,

We all understand in an ideal (and also little changing world), we'd have very wide prereq ranges, such as [1.0.0,

2.0.0) thus making the claim that our use of API was so clean, and our providers treatment of API changes so precise,

2.0.0) thus making the claim that our use of API was so clean, and our providers treatment of API changes so precise,

−

that our plugin would run on any version of the prereq in that range.

+

that our plugin would run on any version of the prereq in that range. But that's never reality, and I'd like for us to better understand why that is.

==New Function==

==New Function==

Line 44:

Line 44:

So, the purpose of this page is just to document some notes when the lower bounds change, and briefly document why. Hopefully over time, we'll

So, the purpose of this page is just to document some notes when the lower bounds change, and briefly document why. Hopefully over time, we'll

−

see the obvious patterns and discover if there are alternatives or improvements in the rules or processes that would cause us to move up, or not. Note that we are not asking anyone to change what they do, just briefly document it. We think this issue may become more important in the years ahead, as WTP components are better untangled from each other, and used more independently.

+

see the obvious patterns and discover if there are alternatives or improvements in the rules or processes that would cause us to move up, or not. Note that we are not asking anyone to change what they do, just briefly document it. We think this issue may become more important in the years ahead, as WTP components are better untangled from each other, and used more independently.

−

+

=Cases encountered in WTP 3.1 development=

=Cases encountered in WTP 3.1 development=

Line 56:

Line 55:

[bug ???] A case where we could remove a work around, after the platform provided a proper fix.

[bug ???] A case where we could remove a work around, after the platform provided a proper fix.

Latest revision as of 12:46, 30 October 2008

Contents

What squeezes lower prereq range bounds?

We all understand in an ideal (and also little changing world), we'd have very wide prereq ranges, such as [1.0.0,
2.0.0) thus making the claim that our use of API was so clean, and our providers treatment of API changes so precise,
that our plugin would run on any version of the prereq in that range. But that's never reality, and I'd like for us to better understand why that is.

New Function

One obvious place this begins to change is when new function is added to a minor release, and we want to
use that new function, so we have to bump-up the lower limit to match whatever version that new
function appeared in.

Service fixes

Similarly, there may be some fixes in a service release that we know are important to our correct operation, so we
want to prereq that service version.

Grey areas

I'll start with two hypothetical cases, just to illustrate it's not always so obvious as I make it out to be above.
Imagine the "new function" case. Sure, we in WTP could prereq that minor version to make sure we always ran
with that new function. But, we could also solve that problem with packaging ... just making sure the correct version was
packaged by our particular feature line-ups. There might be other users or adopters who don't care about that function,
for their use-cases, so why burden them with having to get the latest version?

In the service area, what if the bug fix that caused the service field increase was not a very important bug?
Could we get what we wanted, via proper packaging, and someone else who didn't care about that bug, continue to run on older prereqs?
You might think this would be rare, but it has recently come up. See bug 251612 for
issues with GEF requiring the latest version of ICU (for what is probably little reason).

What else?

In practice, there's some other reasons that cause us to increase our lower bounds, and
they may not always be so obvious or well understood. We've been operating in the mode that we only run WTP on the
current stream of pre-reqs being produced, so there was no reason to worry about why we had to move up ... we just
move up for any little reason ... real or imagined ... right or wrong.

As we mature, as a development organization, we should pay more attention, and learn more about this. This would not
only help our WTP project, but would help other projects realize when they unnecessarily cause range narrowing, with
out necessarily intending to.

Many of the reasons we document, as we study this, may be subsets of the 'new function' and the 'service fixes' cases, but
it would still be an advancement to understand in more detail.

So, the purpose of this page is just to document some notes when the lower bounds change, and briefly document why. Hopefully over time, we'll
see the obvious patterns and discover if there are alternatives or improvements in the rules or processes that would cause us to move up, or not. Note that we are not asking anyone to change what they do, just briefly document it. We think this issue may become more important in the years ahead, as WTP components are better untangled from each other, and used more independently.

Cases encountered in WTP 3.1 development

bug 246665. This was a case where we used non-API from platform,
they finally provided the API we requested, AND they initially removed the non-API completely, causing not only an immediate
break, but also forcing us to specify a higher prereq. In this particular case, they eventually backed off, and agreed to leave
in the non-API, deprecated of course, so people could "move up" when most convenient

[bug ???] A case where we could remove a work around, after the platform provided a proper fix.

bug 252788. Case of a non-api changing names.
This was actually in a old, minor test-related plugin, not mainstream code.