Once upon a time I published my library "ScrollMagic" for bower.
For lack of knowledge and proper reading (shame on me) I did not adhere to the "lowercase only" naming convention.
With version 2.0.0 i changed that and now it's all lowercase.
How do I go about fixing that?
Removing "ScrollMagic" is likely to cause problems with people who already set it as a dependency.
But I can't publish as "scrollmagic" because it says the package already exists.
What do I do?
Related
I have an old MVC application I need to make changes to. It would be nice to update all the recommended NuGet packages, but I know from experience that this can break a project.
In particular, I'm troubled by the following:
If one reads this a certain way, it appears that it's actually suggesting I upgrade to Twitter Bootstrap 5.1.2. I know for a fact that numerous breaking changes have been implemented since my current version.
I prefer not to have to rewrite the site. I thought Updates might have been a little smarter. Do I really need to know each package well enough to know if it would include breaking changes? Is there no way to specify compatible updates? Did Microsoft consider this aspect?
You do need to know each package well enough. Why? Because there's not a single way of doing versioning. Some packages, probably a lot of packages even, follow Semantic Versioning, but there's nothing to stop anyone from using any versioning they want (even if it doesn't make sense). There's nothing preventing you from going 3.0.1 to 15.14.13 with a change in an unimportant .txt file.
It's your responsibility to know what to update and when. Look at this Q&A to see how you can restrict the versions suggested: NuGet Limit max major version of a package
I know most projects have minimum versions defined in bower.json for a lot of libraries.
Something I don't understand is that would this be risky that if something updates and have break-changes or bugs, it will affect your application without you knowing it? What is the design thinking behind this?
Thanks!
We have just faced that exact issue on a project I am on, and the solution was to change our bower.json file to target fixed versions.
Specifically, we were targeting angularjs ^1.4.8. In AngularJS v1.6,
$location now uses '!' as the default hash-prefix for hash-bang URLs,
instead of the empty string
For better or for worse (mostly for worse) we had some hard-coded urls in a different application that pointed to this project that broke once bower automatically installed AngularJS 1.6 as part of our automated build process.
The solution was to simply lock down our versions rather than relying on the latest bug fix (i.e prefixing version numbers with ~) or minor build (i.e. prefixing version numbers with ^).
I think the reason that package managers like bower and npm default to dynamic versions is that they rely on semantic versioning, and in theory you should only encounter breaking changes when the major version number changes. Semver uses a major, minor, bugfix pattern. When the bugfix value is incremented it indicates that one or more backwards-compatible bugs have been resolved. When the minor version is incremented it indicates that new backwards-compatible functionality has been added. When the major version is incremented it indicates that new, breaking changes have been introduced.
The problem with this is that firstly, it relies on the package developer to respect the semver rules when they make changes to their packages, and secondly, even when semver is respected it can still lead to problems (as in the example I provided above).
This is the error messsage I get.
I know it's kind of an eye roller, that it's difficult nigh impossible to tell what I may need without the source, but it seems like a deployment problem as people that installed the Qt SDK can run it. Plus, I figured I'd have better luck asking here than with a chinese developer that speaks google-english.
So here's what I've done:
I installed the MSVC2012.
I used a program called cffexplorer to see what the exe was looking for. I have the 7 or so .dlls that are at the top of the tree.
I found a recent (jun 2013) qwindows.dll from elsewhere on my system and put it in ./plugins (I've tried this file in ./, ./plugins, and ./plugins/platforms
I created a qt.conf with the following data (I determined the format from an existing Qt based app that works)
[Paths]
Plugins = plugins
Yet, I continue to get this message. Any suggestions on what I might look for to clear this up?
Ask the developer what compiler was used to build the application. Then you will need the right dll (that was built with the same compiler as the application). Also notice that (by default) the documentation says that qwindows.dll should be in the platforms folder in the same path as your executable, read more here. Depending on whether the developer used a Qt built with angle, you may also need: libEGL.dll and libGLESv2.dll. Dependency walker might help you find dependencies that are not there.
It just baffles me that even though upddates show up in the Manage NuGet Packages UI for a solution, clicking the update button results in a process that looks like it should work and then fails at the end for no apparent reason. I always have to fall back to uninstalling by hand, removing the project references for the library, and manually deleting the reference from the project file. (Why remove does not do this I have no idea.)
My Setup:
VS2012RC - maybe this works in VS2012RTM?
NuGet v2.1 - the latest as far as I know
F# - I've only been working in F# lately, maybe the problem is specific to F#?
FSharpx.Core - this is the library I update all the time, but I have experienced it with others
At first the messages look like it is working (upgrading from 1.6.78 to 1.6.83)
Added file 'FSharpx.Core.1.6.83.nupkg' to folder 'FSharpx.Core.1.6.83'.
etc.
Successfully installed 'FSharpx.Core 1.6.83'.
'FSharpx.Core 1.6.83' already installed.
Looking for updates for 'FSharpx.Core'...
Updating 'FSharpx.Core' from version '1.6.78' to '1.6.83' in project 'DS_Benchmark'.
'packages.config' already exists. Skipping...
Successfully removed 'FSharpx.Core 1.6.78' from DS_Benchmark.
'packages.config' already exists. Skipping...
Maybe skipping 'packages.config' is the problem, since the version should be updated in that file.
Then the messages start looking bad. Just installed files start getting removed.
Removed file 'FreebaseTypeProvider.htm' to folder 'C:\Users\Jack\Documents\GitHub\DS_Benchmark\packages\FSharpx.Core.1.6.83\...
etc.
Successfully uninstalled 'FSharpx.Core 1.6.83'.
(As an aside, could NuGet please use the correct preposition for "remove" in their message?)
It's a bug in NuGet 2.1, or else a change to the F# project system in VS 2012 that breaks NuGet.
http://nuget.codeplex.com/discussions/395351
They've acknowledged the problem, and pledge to have it fixed in NuGet 2.2. In the meantime, you can help by voting for the bug, and also this other NuGet/F#/VS2012 bug.
I believe I have put the question quite clearly and in a concise manner. Why do I ask?
I am to explain Ruby on Rails framework to students and this requires me to make some analogies to the Java world (as the course is quite Java-centric). I have no hands-on experience with Ruby on Rails but I sense the Gem/Jar analogy is a valid one.
Could anyone perhaps shed more light on this issue?
As a short answer I would say: Yes, it is valid.
As a long answer I would say: Yes, it is valid, but there are some important distinctions you may want to describe as well.
A jar has some qualities that makes it very different from a gem. JARs are packaged executable libraries that you generally have to explicitly declare a dependency upon in a Java program's execution at invocation time (by declaring the jar as a dependency when you invoke the java interpreter). The jar has little structure enforced upon it other than a few well defined locations for files (e.g. directory structure must mirror package path).
A Gem is a descriptor for installing a library to a system permanently as well as a package of functionality made available to be declared a dependency during runtime. A gem has a strict versioning syntax as part of its definition, and gems tend to be distributed from few centralized repositories that spend a decent amount of effort to ensure uniqueness in gem names. Gems can explicitly declare their dependencies on other gems. (Contrast with JARs where you must make sure you have all of the dependencies for a jar satisfied at invocation time and jars do not explicitly adopt the responsibility for dependency declaration OR resolution). Additionally there is some optional functionality built into the gem tool that can be quite convenient, for example you can declare a default executable for a gem to be invoked if a user wishes to "run a gem", and you can declare a unit testing suite for a gem so that a user who installs a gem can ensure its functionality.
Also you might want to describe to your students that RubyGems is a tool created independently of the Ruby language itself, and that it benefits after many of the inconveniences and complaints that arose from managing jars had been well exposed from years of Java development.
I'm not sure is that easy...
I think that a Gem is basically the same thing as a jar, but a Gem has to have a name and a version, a jar does not have this, hm, let's say..., restrictions.
The Jar mechanism was created for packaging and just for packaging.
The most important, IMHO, in the Gem is the RubyGems project
The RubyGems feature set is a little larger than just packaging, in involves package distribution and installation.
I think that the Apache Maven distribution and installation mechanism is the closest thing the Java community has from the Ruby Gems.
As a simple explination comparing them to JARs is good enough for a basic Ruby class. For a more detailed explination see holychao's answer. The analigy that comes to mind for me is that Gem's are to Ruby what CPAN is to Perl.