We're excited to announce IPM version 0.12.0, a release focused on making package management more intelligent and giving developers precise control over their build processes. This update addresses two key areas that teams have been asking for: better package visibility and standardized build exclusion patterns.
Package Intelligence: Know Before You Download
One of the most frustrating aspects of package management is making decisions with incomplete information. Which version should you use? Is this package actively maintained? How popular is it within your organization or the broader community?
IPM 0.12.0 transforms the ipm info command into a comprehensive package intelligence tool.
Complete Version Visibility
Instead of just showing the latest version, you now see the last 6 versions at a glance:
ipm info --package avm-bicep/virtual-networks
AVM-BICEP/VIRTUAL-NETWORKS v0.5.3
Info
------------------------------------
Owner: 🏢 avm-bicep
License: MIT
Type: Bicep
Published: Sun, 23 Feb 2025 06:29:47 GMT
Total files: 9
Downloads: 16
Dependencies:
- avm-bicep/utl-common-types v0.2.1
Description
------------------------------------
This Bicep AVM module deploys a Virtual Network (vNet).
Readme
------------------------------------
REMOVED for reading
Other versions
+------------------------------------------------+
| Version | Published | Total files | Downloads |
|---------+------------+-------------+-----------|
| 0.5.3 | 2025-02-23 | 9 | 16 |
| 0.5.1 | 2024-11-05 | 9 | 16 |
+------------------------------------------------+
This gives you immediate insight into release frequency, version patterns, and helps you make informed decisions about which version fits your stability requirements.
Usage Statistics That Matter
The new download statistics and file counts provide crucial context:
- Download counts help you gauge community adoption and trust
- File counts give you a sense of package complexity before download
- Verification badges provide immediate security assurance
This intelligence is particularly valuable when evaluating multiple packages that solve similar problems.
Standardized Build Control with .ipmignore
The second major enhancement addresses a long-standing challenge: precise control over what gets included in your packages. Until now, you relied on our built-in exclusion rules, which worked well for common cases but couldn't handle every scenario.
Familiar Syntax, Powerful Control
We've implemented .ipmignore using the same syntax as .gitignore, so you already know how to use it:
# Exclude all log files
*.log
# Exclude development directories
dev/
testing/
.vscode/
# But include specific important files
!.ipmignore
Intelligent Exclusion Reporting
When you run builds, IPM now tells you exactly why each file was excluded:
ipm build -s ./src/ --dry-run
Building package contents from folder '/workspace/build/src/'...
Preparing a new package from local folder '/workspace/build/src/'...
Preparation done with warnings: 3 file(s) skipped due policies in place.
Dry Run - Package Preview
── Files to be included ─────────────────────────────────────────────────────────────────────────────────────────
╭────┬──────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ # │ Path │
├────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ 1 │ /workspace/build/src/CHANGELOG.md │
│ 2 │ /workspace/build/src/DISCLAIMER.md │
│ 77 │ /workspace/build/src/table-service/README.md │
│ 78 │ /workspace/build/src/table-service/table/main.bicep │
│ 79 │ /workspace/build/src/table-service/table/README.md │
╰────┴──────────────────────────────────────────────────────────────────────────────────────────────────────────╯
── Files to be excluded ─────────────────────────────────────────────────────────────────────────────────────────
╭───┬──────────────────────────────────────────────────────────────────────────────────────┬────────────────────╮
│ # │ Path │ Reason │
├───┼──────────────────────────────────────────────────────────────────────────────────────┼────────────────────┤
│ 1 │ /workspace/build/src/ipmhub.manifest.json │ FileIsOnIgnoreList │
│ 2 │ /workspace/build/src/storage-accounts/ipmhub.manifest.json │ FileIsOnIgnoreList │
│ 3 │ /workspace/build/src/storage-accounts/packages/utl-common-types/ipmhub.manifest.json │ FileIsOnIgnoreList │
╰───┴──────────────────────────────────────────────────────────────────────────────────────┴────────────────────╯
── End of Dry Run ────────────────────────────────────────────────────────────────────────────────────────────────
This transparency eliminates guesswork and helps you fine-tune your package contents.
Solving Real-World Scenarios
The .ipmignore functionality addresses common packaging challenges:
Scenario 1: Development Tools
You have development scripts that shouldn't be in production packages, but you need certain executables included.
Scenario 2: Documentation Structure
You want to exclude draft documentation but include final docs, even if they follow similar naming patterns.
Scenario 3: Multi-Environment Configs
You need to exclude environment-specific configs while including templates.
Default Exclusions
IPM now ships with an extensive list of default exclusions covering common development artifacts:
- System Files:
.DS_Store,.Thumbs.db, temporary files - Build Artifacts:
.dll,.exe,.so, compiled objects - Development Tools:
.vscode,.idea,node_modules - Version Control:
.git,.svn, ignore files - Language-Specific: Python cache, Java classes, PowerShell configs
The complete list ensures your packages stay clean and production-ready by default.
Override Capability
Some files are marked as "ignored by default" rather than "excluded" - meaning you can include them if needed:
# Include PowerShell configuration files
!*.ps1xml
# Include batch scripts for deployment
!deploy.bat
# Include the ignore file itself for transparency
!.ipmignore
Extended Package Names: Better Organization
Based on your feedback, we've extended package name support from 36 to 64 characters. This seemingly small change has significant organizational benefits:
# Now possible: descriptive, searchable names
myorg/azure-kubernetes-cluster-with-monitoring-and-security
company/multi-region-disaster-recovery-infrastructure
myorg/comprehensive-network-security-baseline-template
Longer names improve discoverability and reduce the need for additional documentation to understand package purpose.
The Development Experience Impact
These improvements work together to create a significantly better development experience:
- Faster Decision Making: Rich package information helps you choose the right components quickly
- Predictable Builds: .ipmignore gives you precise control over package contents
- Better Organization: Longer names improve package discovery and categorization
- Reduced Surprises: Clear exclusion reporting eliminates build mystery
Real-World Application
Consider a typical workflow improvement with 0.12.0:
Before: Check package, download, build, check what was included, adjust, rebuild
After: Check comprehensive package info, configure .ipmignore once, build with confidence
The time savings compound across your team and organization.
Upgrade and Implementation
IPM 0.12.0 is available immediately through all standard channels:
- Windows: winget upgrade IPMHub.IPM
- macOS: brew upgrade ipm
- Direct download from our website
All existing functionality remains unchanged. The .ipmignore feature is opt-in, so your current packages continue building exactly as before.
Looking Forward
This release represents our continued commitment to making infrastructure package management more intelligent and developer-friendly. The enhanced package intelligence and standardized build control provide the foundation for even more sophisticated package management features planned for future releases.
About IPMHub
IPMHub streamlines Infrastructure as Code distribution through comprehensive package management. Our platform helps teams maintain consistency and efficiency in their infrastructure deployments through features like Tracked Workspaces, verified packages, and now enhanced package intelligence.