aspose file tools*
The moose likes HTML, CSS and JavaScript and the fly likes Version Control of Deployed jQuery, jQuery UI, Plugins, Extensions Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of JavaScript Promises Essentials this week in the JavaScript forum!
JavaRanch » Java Forums » Engineering » HTML, CSS and JavaScript
Bookmark "Version Control of Deployed jQuery, jQuery UI, Plugins, Extensions" Watch "Version Control of Deployed jQuery, jQuery UI, Plugins, Extensions" New topic
Author

Version Control of Deployed jQuery, jQuery UI, Plugins, Extensions

Eric Bresie
Greenhorn

Joined: Apr 05, 2011
Posts: 20

May be beyond the scope of Extended JQuery book but...

I was curious about was revision control of jquery, plugins, extensions, etc of files during deployment (i.e. not how things are saved via version control system like git, svn, etc). How do you deploy the items and make code maintainability for future upgrades easy?

Is it best to keep jquery / jquery ui version file names (jquery-1.8.0.js) to insure the version compatibiltiy is know, which means when you change versions, you have to change ever file with the specific previous version filename?

Do you rename to a non-version specific version filename (jquery-1.8.0.js to jquery.js)? This seems like it could potentially lead to issues later down the line if api or behavior changes.

If an api/plugin change how way to handle this (keep a copy of the old plugin and its required jquery/jquery ui or refactor all the code)? Then you risk having many versions of the same product causing confusion.

I assume good way is to have a "wrapper"/ "adapter" layer to help reduce version dependencies, but that seems like it could also add extra code..

Eric Pascarello
author
Rancher

Joined: Nov 08, 2001
Posts: 15376
    
    6
The worst thing a project can do is assume that swapping out jQuery without the version number is safe. When you swap out that file, that JavaScript file will live in browser and proxy caches and will be wrong. So when you call for a certain method, it might be the wrong up.

Keith Wood
Author
Ranch Hand

Joined: Aug 28, 2012
Posts: 38

I think you should include the version number in the file reference - in the path if not in the file name itself. As you note, this provides simple and clear documentation about which version is used/required for the page and helps to avoid using a different version that may or may not include a particular function. Most server-side frameworks let you include common snippets into your pages, so you should be able to have an include file that lists the JavaScript libraries and then only have to change it in one place.

At least jQuery and jQuery UI include version numbers that you can check if necessary - $.fn.jquery and $.ui.version respectively - although testing for the actual function/attribute may be a safer option. Maybe there should be a common mechanism to enquire about the version of a particular plugin. A compatibility wrapper can be useful to help users upgrade to a newer version, and is only required when older (deprecated) functionality is still required. Those users that follow the upgrade path can ignore it.


Author of the upcoming "Extending jQuery" book from Manning.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Version Control of Deployed jQuery, jQuery UI, Plugins, Extensions