On ചൊവ്വ 06 ഡിസംബര് 2016 01:26 രാവിലെ, Paul Gevers wrote: > What we need is improved handling of transitions in the JavaScript area > of our archive. Having jquery (and jquery-ui) not updated for stretch, > was IMHO also not an option. But these kind of thing need to trigger > proper transitions, like we do for libraries. After many days of troubleshooting, we have fixed this issue. jquery-ui-rails was not just embedding jquery-ui, but adapting it for sprockets/rails assets pipeline by adding dependency information at the top of the file. We now build ruby-jquery-ui-rails from node-jqueryui. > I believe that jquery was believed to be backwards compatible (at least > that is what I understood from the logs). I felt that I had to fix the > jquery-ui situation before stretch, mostly because the old package > wasn't build from source. I could have filed an RC bug about that but I > believe the maintainer isn't active in Debian these days, so that > wouldn't be a great solution. I decided to fix the package myself and > take the blame.... So I am taking the blame here and now. I didn't > realize how fragile the JavaScript interface in our archive is. There was a clear breaking of api. all jquery-ui/<widget> changed to jquery-ui/widgets/<widget> and similarly for effects. At least jquery-ui-rails author marked the breakage with clear major version update. > Sorry, and to prevent further damage, I'll not touch existing JavaScript > packages again. That is not a good outcome either. I also broke things in the past and got even stronger responses from affected maintainers (http://lists.alioth.debian.org/pipermail/pkg-go-maintainers/Week-of-Mon-20161010/007756.html), after testing the direct reverse dependencies, but did not transitively check all, but I did not stop. What I suggest is the following, 1. When handling fragile languages (javascript, ruby, go and possibly more), we should not assume minor versions will not introduce breaking changes, at the minimum when dealing with development versions (in SemVer language, <= 0). 2. Ask the upstream about their policy of updates. Ask them if they follow SemVer or can consider it. https://wiki.debian.org/Teams/Ruby/UpstreamPledge I have got many positive replies (to my surprise) from many ruby gem authors. 3. Check the changelog for any possible breaking changes, even if it is removing deprecated apis, reverse dependencies need time to update. 4. Don't assume all upstream would have already updated to the new version in 6 months. 5. Use tools like build-and-upload script from pkg-ruby-extras so we know reverse dependencies with defined tests are not broken at least. 6. Increase the test coverage in the repo so library updates can be easily tested using tools like build-an-upload. At the least try to add a few smoke tests (just add require/import/include of the library - so at least file name changes can be caught) 7. Even with all this, we may break things, but then please help the affected maintainers to fix the issue. Having to fix all breakages alone when you are maintaining packages with long list of dependencies (like gitlab, diaspora, prometheus etc) is really demotivating.
Attachment:
signature.asc
Description: OpenPGP digital signature