[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: howto handle jquery embedding by build-depends



Hi Vincent,

Quoting Vincent Bernat (2014-05-08 13:52:01)
> ❦  8 mai 2014 11:45 +0200, Thorsten Glaser <tg@debian.org> :
> 
>>> /usr/share/doc/doxygen/README.jquery
>>
>> This is a bug in doxygen. Replacing the embedded jquery copy in the 
>> Debian package shipping it with a link to the jquery version in 
>> Debian should be the right thing to do. Maybe this entire technology 
>> behind doxygen needs gentle kicking, like people such as Torsten 
>> Werner did to Java™ stuff, to get it to conform to our expectations.
>
> Yeah, let's ignore the others and say them they are wrong.
>
> In the JS world, they rely on "semantic versioning". In theory, this 
> says that version x.y+1.z is backward-compatible with x.y.w. In 
> practice, this is not always the case and automatic upgrade from one 
> minor version to another one should be done with care. jQuery is 
> mature enough to be more immune to this problem but many wide-used 
> libraries have this problem. For example, Twitter Bootstrap as in 
> Debian is 2.0.2 (quite old). The latest version for the 2.x serie is 
> 2.3. It is quite unlikely that a project using 2.0 can use 2.3 without 
> additional modifications.
>
> By forbidding embedded copies without providing a sensible alternative 
> (like a package with all minor versions of jQuery), we are just 
> introducing bugs in our packages making them of lesser quality.

You mention yourself that jQuery likely isn't as bad as e.g. Bootstrap, 
yet you describe only the extreme alternative of needing *all* versions 
of jQuery packaged.

I suggest that each package feeling the need for a specific version of 
jQuery (or any other JavaScript project) file a bugreport against 
corresponding package to get that version maintained properly.

Then we can revisit this issue in some months when we have a more 
realistic picture of a) how many versions of various code projects are 
really needed, and b) how maintainers of those code projects feel about 
maintaining code which is possibly abandoned and unmaintained upstream.

...and depending on b) we can then also discuss how maintainers of 
non-JavaScript packages expect to do a better job at maintaining such 
code - but let's first explore if possible for Debian to keep current 
separation of responsibility, before going down other paths.


> It is already difficult to make people understand how we work with our 
> release cycle. We don't need angry users and angry upstream because we 
> modify packages to introduce additional bugs.

Agreed.


> Like other languages, Javascript will mature and will handle those
> problems with their community. In the meantime, we need to be flexible
> and tolerant.

I think we can help JavaScript projects mature faster by tracking which 
projects comply with semantic versioning and which do not, instead of 
just assuming they don't comply.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

Attachment: signature.asc
Description: signature


Reply to: