Skip to content
Permalink
Browse files

Updating the source version to 1.4.3pre.

  • Loading branch information
jeresig committed Feb 14, 2010
1 parent efe51cd commit 7e6b20e2e813e774ce970d17215260d54bf15cd7
Showing with 1 addition and 1 deletion.
  1. +1 −1 version.txt
@@ -1 +1 @@
1.4.2
1.4.3pre

40 comments on commit 7e6b20e

@DBJDBJ

This comment has been minimized.

Copy link

DBJDBJ replied Jun 25, 2010

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

@adamramadhan

This comment has been minimized.

Copy link

adamramadhan replied Jun 25, 2010

ah yes a good idea. but what with the datetime ? 1.4.3pre should just do.

@jdodds

This comment has been minimized.

Copy link

jdodds replied Jun 25, 2010

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.

@getify

This comment has been minimized.

Copy link

getify replied Jun 25, 2010

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

@DBJDBJ

This comment has been minimized.

Copy link

DBJDBJ replied Jun 26, 2010

Ok, then , since there seems to be some kind of universal agreement, I shall be so bold to recap:
TITLE : jQuery version-ing feature

  1. ADDED: jQuery.version , in the form of an object (perhaps something like my attempt above)
  2. 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.

--DBJ

@padolsey

This comment has been minimized.

Copy link
Contributor

padolsey replied Jun 26, 2010

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

'1.2.4' > '1.2.3'; // true
'1.3.2' <= '1.3.3'; // true
'1.3.0' > '1.3.0'; // false
@jdodds

This comment has been minimized.

Copy link

jdodds replied Jun 26, 2010

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

@getify

This comment has been minimized.

Copy link

getify replied Jun 26, 2010

@jamespadolsey -- when you always specify all 3 parts, yes... but:

"1.4.0" == "1.4" // false
"1.4.0" > "1.4" // true

@getify

This comment has been minimized.

Copy link

getify replied Jun 26, 2010

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) { ... }

@dmethvin

This comment has been minimized.

Copy link
Member

dmethvin replied Jun 26, 2010

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.

@n3dst4

This comment has been minimized.

Copy link

n3dst4 replied Jun 26, 2010

@jamespadolsey That only works for single-digit components.

"1.13" > "1.3" // false

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.

@DBJDBJ

This comment has been minimized.

Copy link

DBJDBJ replied Jun 26, 2010

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

@padolsey

This comment has been minimized.

Copy link
Contributor

padolsey replied Jun 26, 2010

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?

@getify

This comment has been minimized.

Copy link

getify replied Jun 26, 2010

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.

@jdodds

This comment has been minimized.

Copy link

jdodds replied Jun 26, 2010

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

@DBJDBJ

This comment has been minimized.

Copy link

DBJDBJ replied Jun 26, 2010

@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:

  1. jQuery.version as an simple object
  2. versioning tag composition documented in the form of the minimal grammar (BNF)
  3. 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 ?

DBJ : +1

@dmethvin

This comment has been minimized.

Copy link
Member

dmethvin replied Jun 26, 2010

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

@jzaefferer

This comment has been minimized.

Copy link
Member

jzaefferer replied Jun 26, 2010

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.

@getify

This comment has been minimized.

Copy link

getify replied Jun 26, 2010

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.

@getify

This comment has been minimized.

Copy link

getify replied Jun 26, 2010

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.

@jdodds

This comment has been minimized.

Copy link

jdodds replied Jun 26, 2010

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

@codenothing

This comment has been minimized.

Copy link

codenothing replied Jun 28, 2010

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.

@jdalton

This comment has been minimized.

Copy link
Member

jdalton replied Jun 29, 2010

mesage

@getify

This comment has been minimized.

Copy link

getify replied Jun 29, 2010

while i agree with jdalton's sentiment, can someone kick him off this thread unless he can be more productive and useful!? :) haha, jdd.

@DBJDBJ

This comment has been minimized.

Copy link

DBJDBJ replied Jun 29, 2010

@getify: Joking aside jdalton has made one of the more productive entries in this thread, which is already beyond the edge of being comical ...

@getify

This comment has been minimized.

Copy link

getify replied Jun 29, 2010

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

@jdodds

This comment has been minimized.

Copy link

jdodds replied Jun 29, 2010

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)

@getify

This comment has been minimized.

Copy link

getify replied Jun 29, 2010

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

@DBJDBJ

This comment has been minimized.

Copy link

DBJDBJ replied Jun 29, 2010

@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

@jdodds

This comment has been minimized.

Copy link

jdodds replied Jun 29, 2010

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.

@kensnyder

This comment has been minimized.

Copy link

kensnyder replied Jun 30, 2010

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+
}

@rkatic

This comment has been minimized.

Copy link
Contributor

rkatic replied Jun 30, 2010

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;
};
@rkatic

This comment has been minimized.

Copy link
Contributor

rkatic replied Jul 1, 2010

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")

@getify

This comment has been minimized.

Copy link

getify replied Jul 1, 2010

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.

@rkatic

This comment has been minimized.

Copy link
Contributor

rkatic replied Jul 1, 2010

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!

@ghost

This comment has been minimized.

Copy link

ghost replied Jul 1, 2010

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.

@rkatic

This comment has been minimized.

Copy link
Contributor

rkatic replied Jul 1, 2010

@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/...)

Future updates at http://gist.github.com/459570

@getify

This comment has been minimized.

Copy link

getify replied Jul 1, 2010

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.

@kensnyder

This comment has been minimized.

Copy link

kensnyder replied Jul 1, 2010

@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?

@DBJDBJ

This comment has been minimized.

Copy link

DBJDBJ replied Jul 2, 2010

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

Please sign in to comment.
You can’t perform that action at this time.