access cookie plugin version

[jpalomar]

access plug-in version via .version

[Krinkle]

Why?

[carhartl]

I was also wondering what the use case for this is, or whether that's now common practice in jQuery land...

[jpalomar]

My intent for this property addition was to easily assess which version a particular project is running. In cases where different versions of libraries are loaded for particular projects sourced from a massive back-end infrastructure, it is helpful to know which versions of a particular jQuery plugin are executed during run-time - especially when libraries are built and minified into a single file. It increases visibility of breaking or compatibility changes with other plugins.

[Krinkle]

@carhartl I'd say it is not common practice for the version to be exposed as a public property among jQuery projects and community plugins. jQuery Core and jQuery UI do do this as being major libraries where users may benefit from being able to condition code based on versions where feature detect may not be feasible. Though even there I'd say it's discouraged from actually being used and just there for legacy reasons.

For other plugins I'd strongly advise against exposing it as a public property. I can only think of bad use cases for it (e.g. hacky code using version sniffing, or unrealistic/ill-informed corporate back-end infrastructure). Including it in the distribution source code makes perfect sense however, but I'd do that as a /*!-style comment atop the file, not through a public property.

@jpalomar Can you elaborate a bit on why a "massive back-end infrastructure" would benefit from an arbitrary property being added to the source code? It's not like it's in a standard location or path, so you'd have to declare the identifier somewhere specifically for jquery-cookie. And even then it sounds rather shady and questionable as to its usefulness (will it execute the code somewhere and extract the version? or perhaps some kind of static pattern matching?). Besides, you'd still a way to specify the version manually as there'll be plenty of plugins that won't expose a version property.

If you need some unique or incrementing version string to use for cache management (e.g. invalidate minification cache or dependency versions) I'd use something like the Math.max() of the mtime of the file(s) in your repo; or the md5/sha1 hash of the file(s) contents. This is, for example, what the ResourceLoader back-end framework does (as used in MediaWiki by Wikipedia).

[jpalomar]

@Krinkle My use case is in applications where pages pull assets from builds managed by different teams and depts. My intent is to actually know what versions of which assets an application is using because there are cases where different versions of the same assets may be initialized and then redefined with a differing version in a script load at a different time on the same page (which is unfortunate, I admit). I understand your hesitation with the public exposure of versions which will allow people to version sniff -- but what are the negative perceptions about version sniffing a plugin version or even a namespace version? Many times I check the version just so I know which version of the API to use. I find knowing which version of which asset I am using to be useful in a develop or maintenance environment. I believe usage exploitation in functional logic is a developer error e.g.; if (x.version === '1.2.3') { do_this(); } compared to if ( $.fn.live ) { $(doc).load($.noop) } else { $(doc).ready($.noop) } -- much akin to browser version detection compared to browser feature detection. I can see that perhaps this should not be exposed on the master branch of the main plugin repo but I am trying to weigh the pros to the cons. Perhaps I can just keep this on my own fork.

[FagnerMartinsBrack]

My use case is in applications where pages pull assets from builds managed by different teams and depts.

It seems to be a problem specific enough to be solved inside your infrastructure.

My intent is to actually know what versions of which assets an application is using because there are cases where different versions of the same assets may be initialized and then redefined with a differing version in a script load at a different time on the same page

I never saw any infrastructure like the one you mentioned, but you could always use jquery.cookie.1.4.1.js filename pattern for every plugin and split the version from there, this way you wouldn't be relying in plugin authors to change anything.