https://bugzilla.redhat.com/show_bug.cgi?id=857992
--- Comment #6 from Gregor Tätzner <gregor(a)freenet.de> ---
(In reply to comment #4)
Think of jQuery plugins: Do we package each plugin seperately? What
if a
webapp bundles a plugin that is only part of that particular webapp?
Do we unbundle it as well?
I guess we need to fundamentally discuss this. I'm unsure if we can make
this in the F18 timeframe.
Regarding jQuery plugins I think it does not harm if we put everything together
in one package? Of course if a js lib is unique/forked it doesn't make sense to
distribute it separately.
(In reply to comment #5)
jquery: latest version is (currently) 1.8.2. , 1.8.1 was released on
Aug 30,
so you'l need to update this package.
If I'm obliged to build it from source I've a problem because nodejs is still
not in fedora. Or would it be ok to use the ready-to-use version from the
website?
In my experience, esp. web developers are pretty ignorant in
bundling/copying external code. And also, most of them don't care for
backwards compatibility.
For example: Django developers: they said about the request to unbundle: Not
having external dependencies is a design choice of Django.
https://code.djangoproject.com/ticket/17982
Django still uses jquery 1.4.2, and I don't see, this will change in the
near future.
agreed, in such cases we should respect the decision of upstream.
jquery's release notes list some changes affecting backwards
compatibility:
http://blog.jquery.com/2012/08/09/jquery-1-8-released/
When breaking other's packages by upgrading to newer versions, you're also
requested to fix those issues. I'm sure, I don't want to do that.
I think we must provide different jquery packages right from the beginning
i.e.: jquery1.7; jquery1.8 and use them explicitly as deps in the packages. If
the maintainer knows for sure that his app supports the next jquery release he
can bump it manually and go to a "higher" jquery package.
--
You are receiving this mail because:
You are on the CC list for the bug.