Search and Top Navigation
#7171 closed enhancement (wontfix)
Opened March 20, 2011 01:55PM UTC
Closed March 21, 2011 01:08PM UTC
Last modified May 06, 2011 03:29PM UTC
Reference only jquery as x,y instead of x.y.z in demos and tests
| Reported by: | thg2k | Owned by: | |
|---|---|---|---|
| Priority: | minor | Milestone: | 1.9.0 |
| Component: | ui.core | Version: | 1.8.11 |
| Keywords: | Cc: | ||
| Blocked by: | Blocking: |
Description
I want to propose a change in the repository structure. Currently, you have in the root:
jquery-1.5.1.js
this is a real problem because for every minor release you generate a lot of noise in the repository log because you have to:
- delete one file
- create a new file which almost identical to the previous (like between 1.4.3 and 1.4.4 of jquery)
- update all demos to point to the new file
it would be possible to mitigate all of this by renaming the jquery file to jquery-1.5.js and pointing all the demos to this new file.
Impact
in this way, every time you update a patch release of jquery in the repository, you have only the actual jquery differences. also, the demos file don't even need to be touched.
in case of a major/minor version change, you don't have any more noise than you currently have for each patch level version change.
Other reasons
Also, i'm tracking several other repositories for custom widgets, and they are also pointing to the jquery version, but it's not updated as often as the main repository (i.e. they don't merge). thus their demos just don't work.
I wish you could implement this change in 1-8-stable and master. It would solve me a lot of troubles.
Attachments (0)
Change History (4)
Changed March 21, 2011 01:08PM UTC by comment:1
| resolution: | → wontfix |
|---|---|
| status: | new → closed |
Changed May 06, 2011 02:32PM UTC by comment:3
I think the way this is currently, for lack of a better word, reckless and pretty uncaring. Its actually a very lot of noise to make this change. Its one line per file but its almost 250 files. This will only grow as more things are added. My proposed solution is much, much, much cleaner, even more clean than this one: http://bugs.jqueryui.com/ticket/7330
Valid reasons for this change:
`jQuery version are released all that often, especially with the new aggressive release schedule put in place.
`By making this change, it makes it easier for people to review the changes without having to scroll through hundreds of file listings and potentially missing something that may actually affect them
`It is still clear which version of jQuery is being used. Just open the jQuery-core file and it shows the version at the top, very clearly. I think the majority of people who care about what version of core is being used would also be smart enough to open the file to see.
`It makes it easier for people to use different versions of jQuery without having to change all the references. Change one file vs changing hundreds vs changing one file and have it incorrectly show the version thats actually being used
`Smaller git repo as its not tracking unnecessary and needless changes
I sure I or others could come up for more reasons on why this change should be made. Other than the false assumption that people won't know which version of jQuery is being used, are there any valid reasons not to make this change? This is how its being done in jQuery Mobile at the moment.
Changed May 06, 2011 03:29PM UTC by comment:4
I have a hard time getting all worked up about a ton of "noise" that occurs as a single commit in the demos and tests folders each time there's a new version of jQuery that gets pulled into jQuery UI. It worries me about as much as the noise that occurs in each source code file header at the new year with a new copyright year. Sure, this is more frequent (these days), but that one's in source code files, not demos and tests html files. And it's also in the head. Easy to ignore as a single commit, easy to ignore as a line.
Anyway, a few significant reasons for having the version number in the url:
- Any number of caches (browser, web server, proxy) could get involved in aggressively caching the contents of the resource jquery-core.js. Changing the name of the file is a sure way to ensure that every time the tests and demos are run the correct version is loaded (whether in development, production, on jqueryui.com, on test swarm, in test swarm clients, on google and microsoft cdns, on code.google.com, on view.jquerui.com. the list goes on).
- The html in the test is part of the test, that is, it's a significant part of the input. While functionally that dependency can be met by the contents of the file. I'm not satisfied with an implicit "grab jQuery as one of the inputs to this test". It needs to be "run this test using jQuery version X.Y.Z" The URI is the right place for this information, not the response for the request for the resource jquery.js or jquery-core.js. If I grab a test file from the 1.7.3 tag and compare it to a test file from the 1.8.9 tag, the diff of the test files better tell me whether they're running a different version of jQuery or not, without having to pull jquery-core.js from each tag and comparing its contents.
- This is not technically noise, it's a significant change to each demo and test file. The fact that the file is changing reasonably alerts anyone interested that the behavior of the demo or test is subject to change, meaning it needs to be run again after the change to guard against regressions. Say for example one remembers to do this for tests but forgets for demos, then the next release to jqueryui.com has a broken demo. Basically it should be harder than changing 1 file as there's such a potential to affect so many files. By having to change all those files, you can't escape the thought "this change could break something. I need to ensure it doesn't in each of these files"
This isn't a change we want to make. Many people use the files exactly as they are in the repository and it'd be a bit confusing to have files with inaccurate version numbers in the filename. Also, there is very little noise per file (one line) and jQuery versions aren't released all that often. Basically we don't view any of your bullet points as problems.