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 <d...@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@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) _______________________________________________ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel