You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The reason will be displayed to describe this comment to others. Learn more.
Would it be an "overkill" to document the logic behind version tags ?
Also, can we please have jQuery.version ?
(v.s. jQuery.fn.jquery )
In the great danger as being tagged "over-engineering" , I would ideally like to have jQuery.version as an object, perhaps :
jQuery.version = { prim : 1, sec : 4, ter : 3, stage : "pre", datetime : "20100625223456",
toString : function () {
return this.prim + "." + this.sec + "." + this.ter + "." + this.stage ;
}
}
This will help to plugin developers when updating their code to conform to some new feature, or gracefully scale back when used with older jQuery version.
And to testers when comparing and documenting tests.
The reason will be displayed to describe this comment to others. Learn more.
I'd be +1 on moving jQuery.fn.jQuery to an object. Add a few methods to check whether the version is greater than, less than, or equal to a passed in version number, and it would make a lot of plugin developers (and plugin users, hopefully) lives a little easier, assuming people use it.
The reason will be displayed to describe this comment to others. Learn more.
Ok, then , since there seems to be some kind of universal agreement, I shall be so bold to recap:
TITLE : jQuery version-ing feature
ADDED: jQuery.version , in the form of an object (perhaps something like my attempt above)
DOCUMENTED: a micro "grammar" of version-ing tags, which developers can rely on
NOTE: I would not go beyond adding jQuery.version object into the core, because of the size issue. All the perceived version object functionality and functions I would like to see in a official plugin, instead. I think separate from the 'metadata' plugin.
The reason will be displayed to describe this comment to others. Learn more.
@jamespadolsey oh, duh! I'll just go over to the corner and hang my head for awhile for forgetting about that. I suppose it may be still worth adding a method to do the comparison, as a convenience and "nudge in the hey use this direction" for plugin authors, but it's right on that line of being easy to consider totally superfluous.
Edit: No, it appears my original suspicions were correct, and I'm just way too quick to assume that other people have really checked what they're telling me.
The reason will be displayed to describe this comment to others. Learn more.
perhaps the one convenience function we could provide is to canonicalize a version string... so automatically take "1.4" and make it "1.4.0" so that all these built operators work correctly. So it could be used like:
The reason will be displayed to describe this comment to others. Learn more.
String comparison works fine as long as version strings have only one digit per non-terminal component, which seems reasonable for at least the next decade or so given our historical release rates. So '1.4.37' is okay but '1.19.2' is right out. Pre-release version nomencature seems like it should change, though, because currently '1.4.3pre' > '1.4.3' which would be the final release. Maybe '1.4.290' ... '1.4.29n' would work; you could add 'pre' or 'beta' to the end of that as well.
Wherever possible it would be preferable to use feature detection for new methods (.delegate() and the like), saving version checks for situations where the behavior of an existing method changed. Usually I end up writing to the lowest common denominator because it is less code and complexity, it would be interesting to see cases where a version check actually saved you code.
The reason will be displayed to describe this comment to others. Learn more.
I'm not saying it's a generically viable solution -- I'm just saying that for the type of version signature used by jQuery, v > v seems to work quite well. @n3dst4 AFAIK, jQuery only has single-digit components. The only edge cases would be "...pre" and perhaps 1.4 > 1.4.0 etc..
I agree with dmethvin about feature-detection. Also, I don't think it's rational to be doing too much version forking anyway -- your plugin should be made to be compatible with a specified range of jQuery versions, it shouldn't have to adapt for each version.
"I think I am (finally) sick and tired of this kinder-garten ..."
I guess you're opposed to constructive discussion then? What exactly does your remark bring to the discussion?
The reason will be displayed to describe this comment to others. Learn more.
internally/automatically canonicallizing the version strings will let us deal with the "b1" and multi-digit parts and so forth, as they come up. we can internally format the version in a way where the built in operators will work correctly.
The reason will be displayed to describe this comment to others. Learn more.
@dmethvin having a version check in a plugin would have recently saved me a few hours of pain. I had been working on an extra, self-contained, feature for an existing site, and I had been working on it outside of the context of the existing site for various reasons that mostly had to do with business politics. I used jQuery 1.4. The site used jQuery 1.3. I ended up inheriting the site (which was surprising), and it turned out that one of the plugins used was dependent on 1.3, and it was dependent in a non-obvious way.
Yeah, the few hours of pain could have been avoided by more thorough checking on my end, or more transparency during this specific process, or by the 1.3-dependent plugin author writing checks, or by the guy who wrote the site I inherited not using that specific plugin (and I won't go into that), but if there was a simple, known, and encouraged way of saying "this plugin works with jQuery versions blah blah blah", that would be another (hopefully common) way of avoiding version-mismatches. For instance, if I didn't inherit the site, I would have possibly ended up passing my code to the person who had it, and they might have had the same pain, but in reverse, as some of my code was dependent on 1.4. I've since moved to doing feature detection and hopefully graceful degradation in my scripts that might be included in environments where I don't have control over the jQuery version used, but I also am not intimately familiar with all the changes between point versions. Sure, I review them, but I don't hold them all in my head.
It's worth pointing out that a built-in way of doing a version check wouldn't have really saved me any code here. It would have saved me time, and presumably it would help plugin authors, and the users of plugins save time as well. Lots of pretty valid arguments can be made about personal responsibility here, and even if a check goes in it would still be up to plugin authors to use it.
Also, rather than changing version nomenclature to allow a straight string comparison, I would prefer breaking up an incoming version string and checking the parts (like setuptools, but we probably don't need quite that level of robustness for version numbers here).
The reason will be displayed to describe this comment to others. Learn more.
@padolsey :: jQuery has grown-up. Therefore some grown-up (minimal) development infrastructure is necessary, to keep development in its tracks.
Github is one example of the infrastructure required and the obvious benefits it provides. Versioning system is next natural requirement. Is Versioning really necessary? Well please note that there is no versioning inbuilt in the GIT. Why not? Wouldn't it be "natural" to have it in GIT? Well not. Because it is important (every non trivial) project specific part of the development infrastructure. And indeed "setuptools" clearly shows the complexity of the subject, for example here: http://corte.si/posts/code/setuptoolssucks.html, which I wanted to avoid.
I think we are all in agreement here, and this is why I have tried to draft one VERY short proposal for a good jQuery team. In case they do agree with it, I am sure they will be perfectly capable to sort out the implementation details. Recap:
jQuery.version as an simple object
versioning tag composition documented in the form of the minimal grammar (BNF)
Perhaps an official plugin that will provide additional functionality to plugin authors community (much like meta-data plugin does)
Can we please be productive , stop the debate, and vote ?
The reason will be displayed to describe this comment to others. Learn more.
@jdodds, that particular one definitely sounds like a crystal ball problem. The author writing the plugin that worked only in 1.3 probably expected that it would work in 1.4 as well. So they had no reason to put a version check in their code at the time. If they had put a "version greater than I've tested" check in the code with an annoying alert or console.log it would have let you know you were in uncharted territory, but I doubt most plugin authors would do that.
If you have the info handy, I'd also be interested to know what caused the plugin to break from 1.3 to 1.4. If this version check is being requested because there are a lot of breaking changes in jQuery's minor version upgrades, then that is the problem and not that we lack a sophisticated version comparator that every plugin author needs to use so their code won't break moving from 1.4.2 to 1.4.3.
The reason will be displayed to describe this comment to others. Learn more.
Note on @jdodds problem: You can load multiple versions of jQuery at the same time, along with dependencies for each. Probably less messy then patching an existing plugin with odd version checks.
The reason will be displayed to describe this comment to others. Learn more.
FWIW, my reason for wanting better/easier version checking was for the use-case of writing "widget" style code that must be embeddable yet self-contained (to an extent) in any arbitrary page. My widget relied on jQuery, but at least the 1.4 branch which had fixed several important bugs for me that aren't feature-testable, namely the dom-ready detection for on-demand loading of jQuery.
Anyway, I only wanted to inject a copy of jQuery 1.4.x if the page my widget was invoked in didn't have jQuery, or its version was lower than 1.4. So I tested for the existence of jQuery and then examined the version string and compared it to "1.4". I wrote a custom little comparison function that did what it seems like that other python toolkit does, which was split(".") the version string and compare part-by-part. Probably overkill, but I wanted that code to be extensible and maintainable if a future developer had a different or more specific jQuery dependency.
So, I did in fact load a second copy of jQuery if the version wasn't sufficient, and then immediately ran the noConflict() to roll back the page to its copy of jQuery and keep my own sandboxed copy privately.
The interesting trick here though is that we should try to develop a solution that is as backwards-compatible as possible, as that's what it sounds like most of us will be using it for. What I mean is, if we change "jquery" from a string to an object, but make that object behave like a string with toString(), we need to make sure we won't make it more difficult to test versions against older jQuery's.
It should be easily/immediately testable if we're dealing with the new improved version functionality or on the old string. Perhaps the typeof check on the property will be sufficient, but I just wanted to make sure we keep that in mind if we're talking about adding functions or changing properties. Let's not make it needlessly too much harder on ourselves backward-compatibility wise.
The reason will be displayed to describe this comment to others. Learn more.
maybe i should have been more explicit: what i mean is, perhaps ALL of the changes we're suggesting should be added via a plugin and not changed in the core code, so that even an old jQuery versions can be "upgraded" on the fly to have better version detection capability.
The reason will be displayed to describe this comment to others. Learn more.
@dmethvin yes, this particular problem was something of a crystal ball type of problem. FWIW, I didn't mean to imply that a version check being present would have absolutely saved me time with this, just that if there was a version check available, (and presumably a "hey, do this when you write plugins" notice in the docs), that it would have been more probable that I wouldn't have wasted some time.
I don't have access to the environment that the code was breaking in at the moment, but the plugin was qtip -- which is known not to work with 1.4. There is supposedly a specific revision of the plugin that does, but I have not tried it, and for this particular case probably won't.
@jzaefferer I could, yes, but I'd strongly prefer not to if possible, and I'd like to be able to check to see if I need to do so in a "canonical" fashion.
I think it's worth noting that I don't think that this version-checking feature would be adding a huge amount of awesomeness to jQuery, or that it would be relieving a huge amount of pain from the use of jQuery (in fact, I personally run into problems with conflicting versions of jQuery rather rarely), but I do think that it would be convenient, and as far as I can tell, it's not an extremely hefty piece of functionality either in terms of size or in terms of difficulty of implementation.
The reason will be displayed to describe this comment to others. Learn more.
I feel like version checking is the equivalent to browser sniffing. Just because there is a certain version, doesn't mean that features cant be added either directly into the jquery core, or through plugins.
The reason will be displayed to describe this comment to others. Learn more.
@DBJDBJ -- i know, i actually like jdd a lot and was just giving him crap.
however, while i hate the jQuery.fn.jquery confusion, it's be even more breaking backwards compatible if we renamed it and/or moved it to a new location. If we think we want to do so, we actually need to alias to the old location, and people are always gonna have to check if the old location variable is there if the new one isn't.
i think the benefits of renaming/moving are less than the negatives of keeping it in this confusing name/location.
The reason will be displayed to describe this comment to others. Learn more.
I really think clarity should take precedence over backwards compatibility in most cases. An alias can exist for a few point releases without a problem, it can be noted in release notes, etc. People who are writing plugins intended to support older versions of jQuery will have to check for the existence of jQuery.version, but as jQuery moves forward, the amount of plugins being written/supported for versions of jQuery without jQuery.version will dwindle. A balance has to be struck between maintaining backwards compatibility and moving forward / cleaning up cruft -- and it's admittedly very hard to get that balance right. (as an aside, I think Python has done it fairly well with how py3k has been being developed)
The reason will be displayed to describe this comment to others. Learn more.
@jdodds -- as i mentioned earlier, if we were to include all of these suggested changes not as part of core jQuery but as a "version" plugin for instance, then it wouldn't matter about backwards compatibility at all because I could load that plugin into virtually any version of jQuery and be able to reliably "detect" its version and compare it to version strings, etc. The plugin could easily take care of "patching" an old jQuery instance with the version info aliased to the new correct location.
I'm highly more in favor of a plugin approach to address this issue than a core jQuery change. That's my +1.
The reason will be displayed to describe this comment to others. Learn more.
@getify: I simpatise with you, but I do not propose a change here. I propose an addition.
If ubiqutously used it is irrelevant if "new version" mechanism is half in the core, half in the plugin, completely in the core or completely in the plugin.
What matters is that it is introduced, made official and followed.
The reason will be displayed to describe this comment to others. Learn more.
Maybe it would be best to take the approach of creating an alias for jQuery.fn.jquery -> jQuery.version in core, and implementing the checking ability as a plugin? People using newer versions of jQuery (and newcomers to jQuery who are looking for a version string) can find it in a sensible place, without requiring very much in the way of backwards-breaking changes. There's kinda two issues here -- some extra functionality that would be nice to have, and an attribute name that doesn't make a whole lot of sense...
I'd still recommend removing jQuery.fn.jquery a point release or two down the road though.
The reason will be displayed to describe this comment to others. Learn more.
Here is a concise comparison function that supports a ton of different version formats
jQuery.versionCompare = (function() {
function norm(v) {
var m = v.match(/^(\d+).(\d+)(?:.(\d+))?(?:\W?(alpha|beta|pre)\W?(\d+)?)?$/),
num = m ? m[1] * 10000000 + m[2] * 100000 + (m[3] || 0) * 10000
- (m[4] == 'alpha' ? 500 : m[4] == 'beta' ? 300 : m[4] == 'pre' ? 100 : 0)
+ (+m[5] || 0) : m;
return num;
}
return function(v) {
var a = norm(v), b = norm(jQuery.fn.jquery);
return a > b ? -1 : a < b ? 1 : 0;
}
})();
Examples run gainst jQuery 1.2.6
'1.2, 1.2.6-alpha-3, 1.2.6beta1, 1.2.6pre, 1.2.6.pre3, 1.2.6, 1.2.7, 1.2.7beta, 1.3'.split(', ').forEach(function(v) {
console.log(jQuery.versionCompare(v));
});
// 1, 1, 1, 1, 1, 0 , -1, -1, -1
Example usage:
if (jQuery.versionCompare('1.4.2') >= 0) {
// use some feature that requires version 1.4.2+
}
The reason will be displayed to describe this comment to others. Learn more.
Why to complicate.
jQuery.checkVersion = function( min, max ) {
var current = jQuery.fn.jquery + 'zz';
min += 'zz';
max = ( max || min ) + 'zz';
return min <= current && current <= max;
};
The reason will be displayed to describe this comment to others. Learn more.
Are you missing 'zz' appended to strings?
Also here an minor improvement:
jQuery.checkVersion = function( min, max ) {
var current = jQuery.fn.jquery + 'zz';
if ( max ) min += 'zz';
max = ( max || min ) + 'zz';
return min <= current && current <= max;
};
So now you can write:
jQuery.checkVersion("1.4")
instead of:
jQuery.checkVersion("1.4.0", "1.4.9")
The reason will be displayed to describe this comment to others. Learn more.
Guys,
Don't mean to poo poo on this great discussion, but maybe it's time to move it to the discussion forum? I like to get updates and comments about a commit, but I think we've moved past that into ideas for developing jQuery's core.
The reason will be displayed to describe this comment to others. Learn more.
@kitgoncharov: well yes, it will fail if John decide to use both pre and alpha/beta and if pre < alpha. Also if you are using both min and max then min have to contain all three numbers. Apart those (negligible) situations, have you spotted other problematic situations?
Now I really have to go sleep... Array(99).join('zz')
EDIT: Here an improved version that would fix the second problematic situation:
jQuery.checkVersion = function( min, max ) {
var current = jQuery.fn.jquery + 'zz';
max = ( max || min ) + 'zz';
min += '0.0.0zz'.substr( min.length );
return min <= current && current <= max;
};
EDIT: min length normalization (for cases where current version contains 0 and pre/alpha/beta/...)
The reason will be displayed to describe this comment to others. Learn more.
I'm inclined to agree with pinhook. This discussion has evolved into a debate over the proper or most efficient ways to implement such a feature.
I think we need to move that discussion to a different forum than this commit comment-thread.
Beyond how to implement the feature (which is honestly not all that interesting to me), we still need to make sure we agree on what we're implementing, if anything. In principle most people seem to agree that a better "version system" is needed. But I think it'd be more helpful for us to contain our discussions to what before how.
The reason will be displayed to describe this comment to others. Learn more.
@getify Yes, a how discussion is in order--elsewhere. It seems the how discussion was brought up for two main reasons: (1) Implementing a pretty robust function can be done with little code and (2) whether implemented in core or as a plugin, John Resig needs to agree to using a tight convention for version strings.
As far as what, I think there is consensus that there is a use case for checking that the loaded version of jQuery is ==, <= or >= a certain version string and the API for that isn't too important as long as it is simple. Does that sum it up?
The reason will be displayed to describe this comment to others. Learn more.
I moved (aka opened) the discussion on the forum.jquery.com, yesterday ...
When started this I knew there will be a debate, but I never envisaged such a vigorous debate.... wchih is good.
7e6b20eThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be an "overkill" to document the logic behind version tags ?
Also, can we please have jQuery.version ?
(v.s. jQuery.fn.jquery )
In the great danger as being tagged "over-engineering" , I would ideally like to have jQuery.version as an object, perhaps :
jQuery.version = { prim : 1, sec : 4, ter : 3, stage : "pre", datetime : "20100625223456",
toString : function () {
return this.prim + "." + this.sec + "." + this.ter + "." + this.stage ;
}
}
This will help to plugin developers when updating their code to conform to some new feature, or gracefully scale back when used with older jQuery version.
And to testers when comparing and documenting tests.
--DBJ
7e6b20eThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah yes a good idea. but what with the datetime ? 1.4.3pre should just do.
7e6b20eThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd be +1 on moving jQuery.fn.jQuery to an object. Add a few methods to check whether the version is greater than, less than, or equal to a passed in version number, and it would make a lot of plugin developers (and plugin users, hopefully) lives a little easier, assuming people use it.
7e6b20eThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I put this in a long time ago and never got much response... would still love to see something like that done:
http://dev.jquery.com/ticket/5882
7e6b20eThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, then , since there seems to be some kind of universal agreement, I shall be so bold to recap:
TITLE : jQuery version-ing feature
NOTE: I would not go beyond adding jQuery.version object into the core, because of the size issue. All the perceived version object functionality and functions I would like to see in a official plugin, instead. I think separate from the 'metadata' plugin.
--DBJ
7e6b20eThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jdodds, "Add a few methods to check whether the version is greater than, less than, or equal to a passed in version number"
JavaScript already has this capability...
7e6b20eThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jamespadolsey oh, duh! I'll just go over to the corner and hang my head for awhile for forgetting about that. I suppose it may be still worth adding a method to do the comparison, as a convenience and "nudge in the hey use this direction" for plugin authors, but it's right on that line of being easy to consider totally superfluous.
Edit: No, it appears my original suspicions were correct, and I'm just way too quick to assume that other people have really checked what they're telling me.
7e6b20eThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jamespadolsey -- when you always specify all 3 parts, yes... but:
"1.4.0" == "1.4" // false
"1.4.0" > "1.4" // true
7e6b20eThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
perhaps the one convenience function we could provide is to canonicalize a version string... so automatically take "1.4" and make it "1.4.0" so that all these built operators work correctly. So it could be used like:
if ($.fn.version("1.4") > $ .fn.jquery) { ... }
7e6b20eThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
String comparison works fine as long as version strings have only one digit per non-terminal component, which seems reasonable for at least the next decade or so given our historical release rates. So '1.4.37' is okay but '1.19.2' is right out. Pre-release version nomencature seems like it should change, though, because currently '1.4.3pre' > '1.4.3' which would be the final release. Maybe '1.4.290' ... '1.4.29n' would work; you could add 'pre' or 'beta' to the end of that as well.
Wherever possible it would be preferable to use feature detection for new methods (.delegate() and the like), saving version checks for situations where the behavior of an existing method changed. Usually I end up writing to the lowest common denominator because it is less code and complexity, it would be interesting to see cases where a version check actually saved you code.
7e6b20eThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jamespadolsey That only works for single-digit components.
Whether this necesarily affects jQuery for now is another question.
Also:
"1.3b1" < "1.3" // false
Python's Setuptools has a (possibly pathological) algorithm for working this stuff out.
7e6b20eThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"...JavaScript already has this capability..."
" ... it would be interesting to see cases where a version check actually saved you code..."
I think I am (finally) sick and tired of this kinder-garten ...
7e6b20eThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not saying it's a generically viable solution -- I'm just saying that for the type of version signature used by jQuery,
v > vseems to work quite well. @n3dst4 AFAIK, jQuery only has single-digit components. The only edge cases would be "...pre" and perhaps1.4 > 1.4.0etc..I agree with dmethvin about feature-detection. Also, I don't think it's rational to be doing too much version forking anyway -- your plugin should be made to be compatible with a specified range of jQuery versions, it shouldn't have to adapt for each version.
"I think I am (finally) sick and tired of this kinder-garten ..."
I guess you're opposed to constructive discussion then? What exactly does your remark bring to the discussion?
7e6b20eThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
internally/automatically canonicallizing the version strings will let us deal with the "b1" and multi-digit parts and so forth, as they come up. we can internally format the version in a way where the built in operators will work correctly.
7e6b20eThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dmethvin having a version check in a plugin would have recently saved me a few hours of pain. I had been working on an extra, self-contained, feature for an existing site, and I had been working on it outside of the context of the existing site for various reasons that mostly had to do with business politics. I used jQuery 1.4. The site used jQuery 1.3. I ended up inheriting the site (which was surprising), and it turned out that one of the plugins used was dependent on 1.3, and it was dependent in a non-obvious way.
Yeah, the few hours of pain could have been avoided by more thorough checking on my end, or more transparency during this specific process, or by the 1.3-dependent plugin author writing checks, or by the guy who wrote the site I inherited not using that specific plugin (and I won't go into that), but if there was a simple, known, and encouraged way of saying "this plugin works with jQuery versions blah blah blah", that would be another (hopefully common) way of avoiding version-mismatches. For instance, if I didn't inherit the site, I would have possibly ended up passing my code to the person who had it, and they might have had the same pain, but in reverse, as some of my code was dependent on 1.4. I've since moved to doing feature detection and hopefully graceful degradation in my scripts that might be included in environments where I don't have control over the jQuery version used, but I also am not intimately familiar with all the changes between point versions. Sure, I review them, but I don't hold them all in my head.
It's worth pointing out that a built-in way of doing a version check wouldn't have really saved me any code here. It would have saved me time, and presumably it would help plugin authors, and the users of plugins save time as well. Lots of pretty valid arguments can be made about personal responsibility here, and even if a check goes in it would still be up to plugin authors to use it.
Also, rather than changing version nomenclature to allow a straight string comparison, I would prefer breaking up an incoming version string and checking the parts (like setuptools, but we probably don't need quite that level of robustness for version numbers here).
7e6b20eThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@padolsey :: jQuery has grown-up. Therefore some grown-up (minimal) development infrastructure is necessary, to keep development in its tracks.
Github is one example of the infrastructure required and the obvious benefits it provides. Versioning system is next natural requirement. Is Versioning really necessary? Well please note that there is no versioning inbuilt in the GIT. Why not? Wouldn't it be "natural" to have it in GIT? Well not. Because it is important (every non trivial) project specific part of the development infrastructure. And indeed "setuptools" clearly shows the complexity of the subject, for example here: http://corte.si/posts/code/setuptoolssucks.html, which I wanted to avoid.
I think we are all in agreement here, and this is why I have tried to draft one VERY short proposal for a good jQuery team. In case they do agree with it, I am sure they will be perfectly capable to sort out the implementation details. Recap:
Can we please be productive , stop the debate, and vote ?
DBJ : +1
7e6b20eThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jdodds, that particular one definitely sounds like a crystal ball problem. The author writing the plugin that worked only in 1.3 probably expected that it would work in 1.4 as well. So they had no reason to put a version check in their code at the time. If they had put a "version greater than I've tested" check in the code with an annoying alert or console.log it would have let you know you were in uncharted territory, but I doubt most plugin authors would do that.
If you have the info handy, I'd also be interested to know what caused the plugin to break from 1.3 to 1.4. If this version check is being requested because there are a lot of breaking changes in jQuery's minor version upgrades, then that is the problem and not that we lack a sophisticated version comparator that every plugin author needs to use so their code won't break moving from 1.4.2 to 1.4.3.
7e6b20eThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note on @jdodds problem: You can load multiple versions of jQuery at the same time, along with dependencies for each. Probably less messy then patching an existing plugin with odd version checks.
7e6b20eThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FWIW, my reason for wanting better/easier version checking was for the use-case of writing "widget" style code that must be embeddable yet self-contained (to an extent) in any arbitrary page. My widget relied on jQuery, but at least the 1.4 branch which had fixed several important bugs for me that aren't feature-testable, namely the dom-ready detection for on-demand loading of jQuery.
Anyway, I only wanted to inject a copy of jQuery 1.4.x if the page my widget was invoked in didn't have jQuery, or its version was lower than 1.4. So I tested for the existence of jQuery and then examined the version string and compared it to "1.4". I wrote a custom little comparison function that did what it seems like that other python toolkit does, which was split(".") the version string and compare part-by-part. Probably overkill, but I wanted that code to be extensible and maintainable if a future developer had a different or more specific jQuery dependency.
So, I did in fact load a second copy of jQuery if the version wasn't sufficient, and then immediately ran the noConflict() to roll back the page to its copy of jQuery and keep my own sandboxed copy privately.
The interesting trick here though is that we should try to develop a solution that is as backwards-compatible as possible, as that's what it sounds like most of us will be using it for. What I mean is, if we change "jquery" from a string to an object, but make that object behave like a string with toString(), we need to make sure we won't make it more difficult to test versions against older jQuery's.
It should be easily/immediately testable if we're dealing with the new improved version functionality or on the old string. Perhaps the typeof check on the property will be sufficient, but I just wanted to make sure we keep that in mind if we're talking about adding functions or changing properties. Let's not make it needlessly too much harder on ourselves backward-compatibility wise.
7e6b20eThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe i should have been more explicit: what i mean is, perhaps ALL of the changes we're suggesting should be added via a plugin and not changed in the core code, so that even an old jQuery versions can be "upgraded" on the fly to have better version detection capability.
7e6b20eThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dmethvin yes, this particular problem was something of a crystal ball type of problem. FWIW, I didn't mean to imply that a version check being present would have absolutely saved me time with this, just that if there was a version check available, (and presumably a "hey, do this when you write plugins" notice in the docs), that it would have been more probable that I wouldn't have wasted some time.
I don't have access to the environment that the code was breaking in at the moment, but the plugin was qtip -- which is known not to work with 1.4. There is supposedly a specific revision of the plugin that does, but I have not tried it, and for this particular case probably won't.
@jzaefferer I could, yes, but I'd strongly prefer not to if possible, and I'd like to be able to check to see if I need to do so in a "canonical" fashion.
I think it's worth noting that I don't think that this version-checking feature would be adding a huge amount of awesomeness to jQuery, or that it would be relieving a huge amount of pain from the use of jQuery (in fact, I personally run into problems with conflicting versions of jQuery rather rarely), but I do think that it would be convenient, and as far as I can tell, it's not an extremely hefty piece of functionality either in terms of size or in terms of difficulty of implementation.
7e6b20eThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel like version checking is the equivalent to browser sniffing. Just because there is a certain version, doesn't mean that features cant be added either directly into the jquery core, or through plugins.
7e6b20eThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
7e6b20eThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
while i agree with jdalton's sentiment, can someone kick him off this thread unless he can be more productive and useful!? :) haha, jdd.
7e6b20eThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@getify: Joking aside jdalton has made one of the more productive entries in this thread, which is already beyond the edge of being comical ...
7e6b20eThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@DBJDBJ -- i know, i actually like jdd a lot and was just giving him crap.
however, while i hate the jQuery.fn.jquery confusion, it's be even more breaking backwards compatible if we renamed it and/or moved it to a new location. If we think we want to do so, we actually need to alias to the old location, and people are always gonna have to check if the old location variable is there if the new one isn't.
i think the benefits of renaming/moving are less than the negatives of keeping it in this confusing name/location.
7e6b20eThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I really think clarity should take precedence over backwards compatibility in most cases. An alias can exist for a few point releases without a problem, it can be noted in release notes, etc. People who are writing plugins intended to support older versions of jQuery will have to check for the existence of jQuery.version, but as jQuery moves forward, the amount of plugins being written/supported for versions of jQuery without jQuery.version will dwindle. A balance has to be struck between maintaining backwards compatibility and moving forward / cleaning up cruft -- and it's admittedly very hard to get that balance right. (as an aside, I think Python has done it fairly well with how py3k has been being developed)
7e6b20eThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jdodds -- as i mentioned earlier, if we were to include all of these suggested changes not as part of core jQuery but as a "version" plugin for instance, then it wouldn't matter about backwards compatibility at all because I could load that plugin into virtually any version of jQuery and be able to reliably "detect" its version and compare it to version strings, etc. The plugin could easily take care of "patching" an old jQuery instance with the version info aliased to the new correct location.
I'm highly more in favor of a plugin approach to address this issue than a core jQuery change. That's my +1.
7e6b20eThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@getify: I simpatise with you, but I do not propose a change here. I propose an addition.
If ubiqutously used it is irrelevant if "new version" mechanism is half in the core, half in the plugin, completely in the core or completely in the plugin.
What matters is that it is introduced, made official and followed.
--DBJ
7e6b20eThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe it would be best to take the approach of creating an alias for jQuery.fn.jquery -> jQuery.version in core, and implementing the checking ability as a plugin? People using newer versions of jQuery (and newcomers to jQuery who are looking for a version string) can find it in a sensible place, without requiring very much in the way of backwards-breaking changes. There's kinda two issues here -- some extra functionality that would be nice to have, and an attribute name that doesn't make a whole lot of sense...
I'd still recommend removing jQuery.fn.jquery a point release or two down the road though.
7e6b20eThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here is a concise comparison function that supports a ton of different version formats
jQuery.versionCompare = (function() {
function norm(v) {
var m = v.match(/^(\d+).(\d+)(?:.(\d+))?(?:\W?(alpha|beta|pre)\W?(\d+)?)?$/),
num = m ? m[1] * 10000000 + m[2] * 100000 + (m[3] || 0) * 10000
- (m[4] == 'alpha' ? 500 : m[4] == 'beta' ? 300 : m[4] == 'pre' ? 100 : 0)
+ (+m[5] || 0) : m;
return num;
}
return function(v) {
var a = norm(v), b = norm(jQuery.fn.jquery);
return a > b ? -1 : a < b ? 1 : 0;
}
})();
Examples run gainst jQuery 1.2.6
'1.2, 1.2.6-alpha-3, 1.2.6beta1, 1.2.6pre, 1.2.6.pre3, 1.2.6, 1.2.7, 1.2.7beta, 1.3'.split(', ').forEach(function(v) {
console.log(jQuery.versionCompare(v));
});
// 1, 1, 1, 1, 1, 0 , -1, -1, -1
Example usage:
if (jQuery.versionCompare('1.4.2') >= 0) {
// use some feature that requires version 1.4.2+
}
7e6b20eThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why to complicate.
7e6b20eThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you missing 'zz' appended to strings?
Also here an minor improvement:
So now you can write:
jQuery.checkVersion("1.4")
instead of:
jQuery.checkVersion("1.4.0", "1.4.9")
7e6b20eThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sorry to be so dense, but what does "zz" have to do with anything? I don't see how it resolves anything being currently discussed.
7e6b20eThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What does 'zz' have to do with anything?
Well it express my current mental lucidity. It' 3:42AM here and I am sleepy... zzzzzzzzzzzzzz...
Can I have the "LAME" overlay also over my post now? It's so cool!
7e6b20eThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Guys,
Don't mean to poo poo on this great discussion, but maybe it's time to move it to the discussion forum? I like to get updates and comments about a commit, but I think we've moved past that into ideas for developing jQuery's core.
7e6b20eThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kitgoncharov: well yes, it will fail if John decide to use both
preandalpha/betaand ifpre < alpha. Also if you are using bothminandmaxthenminhave to contain all three numbers. Apart those (negligible) situations, have you spotted other problematic situations?Now I really have to go sleep... Array(99).join('zz')
EDIT: Here an improved version that would fix the second problematic situation:
EDIT: min length normalization (for cases where current version contains 0 and pre/alpha/beta/...)
Future updates at http://gist.github.com/459570
7e6b20eThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm inclined to agree with pinhook. This discussion has evolved into a debate over the proper or most efficient ways to implement such a feature.
I think we need to move that discussion to a different forum than this commit comment-thread.
Beyond how to implement the feature (which is honestly not all that interesting to me), we still need to make sure we agree on what we're implementing, if anything. In principle most people seem to agree that a better "version system" is needed. But I think it'd be more helpful for us to contain our discussions to what before how.
7e6b20eThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@getify Yes, a how discussion is in order--elsewhere. It seems the how discussion was brought up for two main reasons: (1) Implementing a pretty robust function can be done with little code and (2) whether implemented in core or as a plugin, John Resig needs to agree to using a tight convention for version strings.
As far as what, I think there is consensus that there is a use case for checking that the loaded version of jQuery is ==, <= or >= a certain version string and the API for that isn't too important as long as it is simple. Does that sum it up?
And to where should we take this discussion?
7e6b20eThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I moved (aka opened) the discussion on the forum.jquery.com, yesterday ...
When started this I knew there will be a debate, but I never envisaged such a vigorous debate.... wchih is good.
--DBJ