Fixing a bad package

Sep 7, 2010 at 9:58 PM

One of the things we have on the nu group is how to fix a package when something goes wrong. Currenly that answer is to suffix the version with either a datestamp or an incrementing number.

Say you were putting up someone else's package for them: say sidepop. I put up the package with version 1.0.0.0. Now let's say I forgot to include the package's dependency on log4net 1.2.10.0. Whoops! Now I need a way to correct.

Do we allow someone to delete their version by reuploading the same version with fixes? Do we have them append (1.0.0.0.20100908 or 1.0.0.0.1)?

My vote is to allow the package owner to reupload the same version with the fixes in it.  This does open up some concerns. I think the gems guys moved away from allowing that due to having load balanced servers.

 

Thoughts?

Coordinator
Sep 8, 2010 at 3:47 PM
Edited Sep 18, 2010 at 11:59 PM

I think we need to understand more details around this scenario. For example, there are two possibilities here:

1. Package is hosted on NuPack gallery.

2. Package is hosted elsewhere.

In the second scenario, you have an entry in the NuPack gallery for your package Foo.nupack. But that entry just points to a download on Google Code. The NuPack entry stores a sha512 hash of that package as part of the entry. NuPack verifies that hash when downloading the package. This mitigates a set of attacks where someone somehow hijacks that URL (for example, if you’re hosting a package yourself and your domain name expires) and also guarantees the user that the package they’re getting is the one they’ve requested.

So we should definitely not support the case where someone simply re-uploads a new package to an external package hosting provider (such as google code). In that case, the hashes will not match up and things will break.

But should we allow updating the gallery without requiring they bump the version? I’m leaning towards treating everyone like responsible adults here (famous last words?) and suggest that we do allow it, but provide ample warnings. If you’re changing a file without bumping a version, you should *only* do this if you made a mistake and are fixing it. Code changes, new features, etc, should probably be a new version of the library. Otherwise, you may invalidate the testing that people have done with their packages which depend on yours.

Phil 

Sep 8, 2010 at 5:15 PM

Yes, this is truly for errors in the package itself.  I'm good with warnings, just allowing someone to still run with scissors is the important part. ;-)

Actually now that I think about it, the experience should be the same for both scenarios for simplicity sake. If you have to reupload the same package due to errors, then it's the appending a date or increment to the end of the version and upload a new one.

In other words,

log4net.1.2.9.0.pkg has issues so re uploading is just the same concept as uploading a new version. you would change the version to 1.2.9.0.20100908 and then upload log4net.1.2.9.0.20100908 to the server. 

The community would see this and know that it was a fix for a bad package. Then they can adjust accordingly. At least that is what I've been driving for on the nu project. 

This kind of thing will usually only happen when people are not able to bump the version, ie. they are uploading someone else's package for them.

-Rob

Sep 10, 2010 at 9:04 AM

Agreed. I think that this is the same as pushing history re-writes to a public git repository.

You shouldn't do it unless you have a damn good reason, but you can do that if you really need to.