Package Conventions

Mar 10, 2011 at 11:39 PM

Hi all, we're starting to try and define certain conventions when it comes to creating packages. I started a page to record the various conventions and list proposed conventions. I don't have a lot here yet, but with your help, we'll get more in there.

Mar 11, 2011 at 2:38 PM

This is great stuff. I am glad to see this catching on.

Mar 11, 2011 at 6:07 PM
This is awesome. We should talk about the general stuff that we just now accept as fact for creating packages.

As in I have this product that includes several dlls and integrations to other projects. What is the convention for setting up that package? One package or multiple?

I have a package that has tools. Is that where I put the full application and just the referencing dlls in the lib?

I have a package that is just content. Should I name that differently?

What's a recommended convention for versioning?

Should I delete my old versions?

I am not the package author, but I want to contribute a package. Conventions for that?
What is the difference between an owner and an author?

What is the convention when my package has different libs in different frameworks (i.e. silverlight4 vs net4.0)?
"Be passionate in all you do"

Mar 11, 2011 at 6:18 PM
Following up one of those questions with more - how should I version my package? Should I use the same version as I use for code? When is this not appropriate?
"Be passionate in all you do"

Mar 11, 2011 at 6:46 PM

Great suggestions!

I’ve updated the package conventions page here:

I also updated the Creating a Package page to link to the package conventions page.

One thing I’m trying to figure out is what’s the best way to describe the 2 different type of conventions. Here’s what I wrote:

There are two types of conventions that apply when creating packages. The conventions listed in this page are enforced conventions. These are conventions that are required to follow when building packages. There are also community (or optional) conventions, which are conventions that have been formed by the community which make it easier for others to understand what your package is all about and make use of it immediately. We’ve just started documenting those package conventions and will continue to update them as new ones appear.

If you have better terms to use, please let me know. The point I was getting across is that when creating packages, there’s a set of conventions that NuGet will actually do something with. The others are for the benefits of the people using your package.