Package naming conventions

Sep 7, 2010 at 10:45 PM

I can't remember if we discussed this or not. It's been on the nu google group once or twice...

What kind of naming conventions do we want to push for the packages themselves?

Examples of differing case and "." versus "-"

  • castle.core
  • castle-core
  • Castle.Core
  • Castle-Core

My preference is the first. All lower case names, and if someone decides to capitalize, PLEASE make sure that we are not case sensitive. It doesn't make for a good time for the user. For example, with ruby gems if you were to "gem install magnum" it would error, but if you type "gem install Magnum" it works perfectly. I'm not picking on anyone because we were learning. The convention for ruby gems is "lower-case."

My personal preference is "" - We are DOT net, so we should use dots. :D

We should also talk about version conventions. 

With versioning, I want to see the version of the package be the same as the assembly reference. Four octets. It keeps things easy and when someone opens up the assembly to find out what the references are, they get the four octets for the version. They could take that and specifically

Add-Reference log4net

If the log4net project uses just the first three to talk about their versioning (1.2.9) that is fine, but when I'm trying to add a reference, I want to go to the source of truth for the version and that is the assembly version. So mimicking that with versioning conventions will be awesome. It keeps me from having to keep it in my head that "this project uses 3 and this other project uses 2 octets" because all projects really have four octets whether they decide to use them or not.




Sep 8, 2010 at 4:06 AM

I'm all for the lower case names and putting it forth as a standard. I find the PascalCase or mixed case to be troublesome. Not everyone can agree on what the case should be and if they do, new people that come on-board don't necessarily get it right. Even when I'm referring to some program in a blog entry I'll scour the website for examples of the proper case, hoping it's consistent, but most people make stuff up (trust me, the SharePoint community gets downright wrangy when people use Sharepoint, even trusted news and media services).

Putting forth a practice of all lowercase means there's no ambiguity. We can't guarantee everyone will follow it but if we put it forward ourselves and lead by example and be consistent about it then others might follow (or at the very least we present. a unified front so we don't look like we're not talking to each other and following our own practices).

I have mixed feelings on the dot aspect. From a tradititionist perspective, dots in filenames always meant to me the separator between filename and filetype. I just don't feel castle.core.nuspec looks right. I prefer castle-core.nuspec and castle-core.nupack but that just might be personal preference. If I had to vote my vote would be filename.filetype.

For versioning, we had the discussion around Semantic Versioning ( and I would like to use that both as a standard and a practice. Four octets is fine with the text addition for -beta, -rc, etc. versions (although the Version namespace only supports the four octets, although I could see NuPack handling this via extension methods). I agree that all packages, from a comparison perspective, boil down to using the four octets. Whether they use that in their marketing, log files, and release notes is irrelevant for packaging.

Sep 8, 2010 at 5:05 AM
Edited Sep 19, 2010 at 12:56 AM

I like the idea of the package-name.nuspec convention.

Realistically, though, people will probably name them whatever they want despite our conventions. After all, wouldn’t we want NuPack.nuspec rather than nu-pack.nuspec? ;)

Sep 8, 2010 at 6:11 AM

With the castle-core.nuspec example that doesn't imply every package should be split up in this manner. I think where there are packages with multi-parts (e.g. mvcturbine, mvcturbine-ninject, mvcturbine-castle, etc.) then it makes sense to split it up. I don't think the NuPack name should ever be nu-pack.*, just nupack.*

And yeah, people will levitate to whatever they want and feel comfortable with, despite the best efforts of driving them towards a common standard. The best we can do is agree on one, practice it ourselves, and advocate using it. Some people will latch on, others will form their own variations and others will completely ignore any commonalities and create divergences.

Sep 8, 2010 at 6:49 AM

If we come up with good guidelines (like the framework design guidelines) most people will just follow it.

Sep 8, 2010 at 6:22 PM

The dll for castle core is Castle.Core.dll. Because they have decided to split it up, they consider it Project.Lib (or something like that). So the package name makes sense to be castle-core.

At any rate, we should make sure we are not case sensitive with the naming conventions, b/c if someone uploads a package and has uppercased their package, I still want to get it with all lower case when I'm typing add-reference packagename.

In our case, NuPack is all one word. If nupack itself was a package, and I think it will be, add-reference nupack should get it to me.

Sep 8, 2010 at 6:23 PM

Ah Bil, now I understand why you like the "-".  It's weird for me to reach way up there on my keyboard, instead of the dot, which I am used to grabbing. Very esoteric I know. It's just me though.