[Pkg-javascript-devel] Javascript library versioning

[Pau Garcia i Quiles]

Hi,

We should just treat JavaScript libraries exactly the same way we
treat C/C++ libraries, with soversions and all. That makes multiple
runtime versions co-installable and co-dependable, which would solve
the problem.


On Thu, Jun 14, 2012 at 5:35 PM, Jonas Smedegaard <dr at jones.dk> wrote:
> Hi Andres,
>
> On 12-06-14 at 10:37am, Andres Rodriguez wrote:
>> So, in order [for Ubuntu] to not differ with Debian, we were wondering
>> a few things:
>>
>> 1. Would it make sense to include versions in the installation paths?
>> (i.e. /usr/share/javascript/yui/2.8.2/*.js ,
>> /usr/share/javascript/yui/3.5.1/*.js)
>>
>> 2. According to the YUI loader, the root path to be prep-ended to the
>> combo service is "<version>/build". For this reason, it also makes
>> sense for us to be using versioned installation paths.
>>
>> All of the above would mean a few things:
>>
>> 1. Adjusting current package to contain major versions (at least in
>> the binary package)
>> 2. Upload a new source package for any major version (i.e. 3.5.X)
>>
>> Given that we don't want to differ from Debian, and try to stick with
>> the policy, we were wondering what are your thoughts about this?
>
> First of all: I strongly recommend that you join the Debian JavaScript
> team and treat Ubuntu as downstream of Debian.  Maybe that's what you
> intend already, but that is not clear from above.
>
> It is my impression that upstream JavaScript projects only seldom deal
> with stable APIs.  It generally makes little sense to second-guess API
> promises from version numbers.  Only when explicitly promised upstream
> (like I seem to recall is the case for YUI in particular) it makes
> sense.  And then it makes sense to track the part promised to be
> backwards-compatible (i.e. commonly either major number or a separate
> number, not the full version).
>
> Also, it probably is sufficient to introduce API versioning when
> multiple APIs are needed by applications.
>
> So all in all, I suggest to a) handle it on a case-by-case manner i.e.
> right now only specifically look at YUI (not draw general conclusions
> from that), b) leave current YUI packaging as-is and only introduce API
> subdir for the upcoming backwards-incompatible package, c) check
> upstream what promises they make about stability of their API and use
> that for the API subdir naming (and for package name).
>
>
> How does that sound?
>
>
>  - Jonas
>
> --
>  * Jonas Smedegaard - idealist & Internet-arkitekt
>  * Tlf.: +45 40843136  Website: http://dr.jones.dk/
>
>  [x] quote me freely  [ ] ask before reusing  [ ] keep private
>
> _______________________________________________
> Pkg-javascript-devel mailing list
> Pkg-javascript-devel at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel



-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)