WTP/Architecture/A study of prereq lower bounds

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.

Related Information

bug 224290 We should minimize variety in pre-req'd plugins