Win a copy of Testing JavaScript Applications this week in the HTML Pages with CSS and JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
  • Piet Souris
  • Frits Walraven
  • Carey Brown

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

Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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..

Posts: 15385
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

Posts: 38
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
Goodbye moon men. Hello tiny ad:
Thread Boost feature
    Bookmark Topic Watch Topic
  • New Topic