Thanks for linking to WP-Oomph, Karsten. :) With the newest release of Oomph 1.1 just announced, I''d like to update the plugin. However, when I downloaded the latest version of the documentation the URI in the "Adding Oomph To Your Website" section of the PDF still refers to the old 1.0 release. I tried hitting various URIs on your server (semantic guesswork) but nothing came up. Is the Oomph 1.1 release ready or have I just jumped the gun on this one?

Thanks again (for everything)!

Hi Meitar,

We actually updated the code directly under the 1.0 directory, since the only changes made to oomph.min.js were several bug fixes which we figured would be wanted by anyone using the 1.0 version. The only reason we re-released the installer (and thus changed version) was because we made some functionality changes to the Live Write Plugin. But you raise a really good point -- maybe we should have called the release 1.0.1, or something like that?

@Joshua Allen: Hmm, yeah…that is actually very confusing. Since I''m technically calling executable code on my own site from your servers, I really, really want to easily tell what code I''m running. If you embed a version number into the URI, I expect that I''m only ever running that version of the code. If you change the resource that is returned when I call that URI, you''ve effectively changed the code I''m running without my knowledge. That scares me.

If you want to do something like that, I would suggest aliasing a URI such as latest/Client/oomph.min.js or similar that will always point to the "latest" released version and encourage people to use that. I''d strongly prefer leaving the 1.0/Client/oomph.min.js contents as 1.0 release code only.

As an aside, doing it that way also means tool authors who need a particular version of your script could link against it secure in the knowledge that it won''t change under them. It would also let us easily mirror your versioning scheme. (E.g., your 1.0 was my WP-Oomph 0.1. Your 1.0.1 could be my 0.1.1 or 0.1.0.1, and so on.) In other words, the stability makes it easy to turn the convention into something useful.

@Meitar: Thanks so much for the clear and detailed feedback. We''ll think about how we can make sure our versioning strategy is transparent and predictable. I''m leaning toward your suggestions about giving choice between version-dependant and version-independant, and maybe pubilsh some conventions about what constitutes each portion of the version specifier.

Our intent was to follow the same versioning strategy we use for other widely-used libraries like C runtime library or MSXML. To summarize, bugfixes that don''t change the interface contract (i.e. zero change to API signatures, data formats, etc.) are applied without changing the version number. In addition, starting around 1999-2001, we de-emphasized version-dependant or static binding. For example, it''s pretty hard to distribute and bind to a specific copy of CRT now, you have to jump through all sorts of hoops to avoid the side-by-side version. Another example would be version-dependant ProgIDs for MSXML, which are no longer considered "best practice". In both cases, our goal is to reduce attack surface area in the event of a discovered exploit (perf, DoS, privilege escalation, etc.). People who statically link a specific copy of the library wouldn''t get the fix, and thus would expose the entire Internet to additional risk.

Anyway, I think there is little controversy about a certain class of bugs like security patches -- you would probably want us to patch a certain class of bugs regardless of whether you linked to a specific version or not. But I agree that there are additional nuances when considering web-based libraries like Oomph. Libraries like Dojo and jQuery follow a similar policy as we do (and similar to MSXML and CRT on Windows). But this situation is slightly different, since we provide UI and not APIs. I think certain portions of YUI are the most apt comparison.