Best practices for naming software packages and deployment

[bpavlov]

I would like to know how folks go about naming their software packages.
I got a standard I am ready to settle on, but before I do so I want to make sure I'm taking everything into account.
Format: Name_OSXVERSUPPORTED_DATEYYYYMMDD
Name: The name of the software
OSXVERSUPPORTED: The version supported by the software written in the format of OSX8910 which would tell me OS 10.8, 10.9, and 10.10 are supported.
Date: 4 digit year, 2 digit month, and 2 digit day.

I wonder what issues I may or may not run into with this naming convention.

How would it affect deployment and/or package tracking within Casper?

[muribe]

I've been using something pretty similar though I don't include the day, just YYYYMM. I also had not included the OS version because we're pretty uniform across our organization but that would be useful to know at a glance as well if you have packages that are built for different OS versions.

I wouldn't think this should affect deployment or tracking within Casper except that you'll have a fairly easy time from the JSS or Casper Remote which package to select!

[davidacland]

I normally use name_swversion_date. I agree, intended / supported OS version would be good as well.

That being said, the naming convention would depend a lot on the techs using Casper. We have lots of sites (different customers), lots of JSSes and lots of technicians. Communicating the desired naming convention and enforcing it can be a real challenge.

Strict naming conventions work best with a single Mac admin and get increasingly out of control the more people you being into the mix!

[jennifer]

I don't think its going to affect deployment or tracking in Casper, aside from the ease of you locating it in a list.

I used to do vendor_app_version, Mozilla_Firefox_32.03.pkg. But since incorporating Autopkg into my process, I've changed things to match its naming, usually app-version, Firefox-32.03.pkg. Ultimately the part that I really cared about was keeping it alphabetical, with respect to both the app name and the version number. I hated having Firefox-32.03 showing up above Firefox 33.pkg, or having to search through Firefox and Mozilla_Firefox to find the newest version.

[Look]

We use the same as @jennifer_unger But with spaces for readability
Vendor App Ver.Ver.Ver.pkg adding the vendor is really useful when dealing with Adobe or Microsoft or other multi app vendors.
If you are renaming post adding to Casper Admin and want the file name to mactch be aware if you change this through Casper Admin the change is IMMEDIATELY implemented on the file itself. The reference to it however isn't saved until you manually save in Casper Admin. If for some reason Casper Admin fails to save you end up with orphan files and a pile of grief, so click save straight after changing any filenames through Casper Admin!

[bpavlov]

Thanks everyone. Your responses have been very helpful. I forgot to mention that I do also include the AppVer as well.

Name_AppVer_OSXVERSUPPORTED_DATEYYYYMMDD

Sounds like I should be OK with this naming convention.

@jennifer_unger
I will be looking into AutoPKG soon. Why did your naming conversion change after incorporating AutoPKG?

[bpavlov]

@Look

Thanks for the heads up on that. I should hopefully not run into this problem with this naming convention but still good to know about little quirks like that.

[PeterClarke]

Best to try to keep things in the same alphabetical order.
Since you will tend to accumulate more then one version of the thing.

As jennifer_unger (above) points out you don't want something like
Mozilla_Firefox_32.03.pkg and Firefox_Vn_34.pkg Since one appears under "M" the other under "F"

Sometimes I check back first, in Casper Admin, to see what name format was previously used for a particular product
- So that I can Keep to the same Alphabetical format, ensuring that similar items appear grouped together.

When creating a policy for instance then selecting the pkg - an alphabetic list of pkgs is presented to choose from
it's useful there if related items are clustered together.

Obviously though, the most important thing, is that the item can be clearly identified..
eg 'Dock_config' is not very helpful if you have 8 different types of Dock_config

Dock_Config
Dock_Config_for_Lab_H-J116 - is more specific
Dock_Config_for_Lab_H-J116_2014-Oct - is even more specific and less ambiguous still..

So whatever makes sense..
Stick to the same format for the same things.
Name things clearly and unambiguously with versions and dates if that's helpful.
It can be harder to do then you might first think.. It's easy to get wrong..
- If do do decide that actually something is badly named after all - then rename it, then save straight away.
Like everything, you get better at it with practice.

Having several different people produces packages each with their own idea about naming is a recipe for problems.
- we've been there, done that, and have had to rename some packages.

[bpavlov]

@PeterClarke

Thanks for the pointers. I may or may not include the vendor. Haven't really decided on that one yet. There are some vendors that just don't make too many different products and therefore it doesn't make sense to include their name because it may throw off what you would typically look for. For example, DiskWarrior. I don't think Alsoft DiskWarrior (I'd probably get used to it if that's the route I went). My natural thought is to just look for DiskWarrior since that's pretty much what they make). Of course you have other vendors like Adobe and Microsoft and Apple who have a lot more products in which case it may make sense to include the vendor name. I may just end up with a hybrid system.

Either way, I'll the be sole tech making the packages which makes it easy to manage. The next step will be a documentation system separate from Casper. Even if I'm working alone, I want someone to know what it is that I'm doing and what each package does and includes. But that's a whole separate topic.

Right now it's quite a mess. There were different people creating packages and the naming convention changed a couple of times. So it was no one's fault particularly just a result of multiple people using different naming schemes. The neat thing is I get to start clean and once I've got all software packaged up, all the old stuff will be deleted making reading the list of packages a little easier.

[jhalvorson]

I used to include the vendor name at the beginning of every packaged but then 1/2 of the support team didn't know who made what so I switched to naming the package nearly the same as the application name.

For example:
Instead of Apple_iPhoto-9.6.pkg, it's iPhoto-9.6.pkg since end users and support will see it in Finder > Applications as 'iPhoto'.

Likewise the Office pkg is titled "Microsoft_Office_2011-14.4.6.pkg".

Even if you come up with the perfect naming syntax, you might get an ear full of feedback from the other people that image, deploy or support your Macs.

I have setup several categories that are based on the vendor names. Those that know the vendor name, can then use the category to filter down what they are looking for.

[jennifer]

@bpavlov I'm using Autopkg w/the JSS Importer (see https://github.com/sheagcraig/JSSImporter) You can also do this with AutoPkgr http://www.lindegroup.com/autopkgr. This method automatically mounts your distribution point and uploads the packages to your JSS.

Since it uploads for you, I left the package names the way they appeared and just changed the few I do on my own to match. I'd assume you can write your own Autopkg recipes and customize the file names, but personally, it didn't matter, so I haven't looked into that option.

[Look]

Just because....
Added a feature request for Vendor and Version fields on packages.
https://jamfnation.jamfsoftware.com/featureRequest.html?id=3008
Seems like a good idea to me, but then I'm probaby biased having created it.

[acdesigntech]

We use Vendor_App_Version.pkg as the naming convention. Easy, simple, done. And if one of my site techs whines that he can't find Diskwarrior under "D" I point him to the handy dandy FILTER function in Casper Remote. Command+F works a treat as well when in the JSS web interface. If the search functions are good, who cares in what order things show up? At least this is what works in our environment. Very rarely are we faced with two versions of the same software package, ymmv.

I'll even go so far as to question why anyone cares at all about the naming convention of package files beyond not breaking filesystem rules for filenames? What matters is the name and priority of the package in the JSS itself, not the package filename - and for that we just drop the .pkg extension, and turn the '_'s into a space. I went through the trouble of coming up with a strict priority assignment for app installers, app uninstall packages (thanks adobe, you SOB), app updates, driver installers, etc. Since casper first relies on priority then defaults to alphabetical order for package installs, this works well for us. On those occasions where two packages have the same priority and I must ensure one runs before the other, I pre-pend it with a '00,' '01,' etc. (I have a convention for that too)

I think I might need more coffee…

[jhalvorson]

@acdesigntech is right about the filter functions.

If there is one best practice about naming packages, it would be to remove spaces in the names or known illegal characters. At some point down the road, your files might be deployed via any one of the available or unknown utopian servers/protocols: smb, afp, http, etc.