Understanding File Releases and Revisions

While contributions track every change during development, releases and revisions mark formal milestones in your product's lifecycle. Understanding the difference between everyday contributions and formal releases helps you maintain clear documentation, support manufacturing handoffs, and meet regulatory requirements.

The Three Levels of Version Tracking

1. Contributions (Frequent)

2. Revisions (Periodic)

3. Releases (Controlled)

Understanding Contributions

What is a Contribution?

Contribution Characteristics

• Each contribution gets a unique commit hash

• Commit hashes are auto-generated (e.g., d27710, f5cc92)

• Hashes are permanent and immutable

• You write a description of what changed

• Message is searchable and visible in activity log

• Good messages help team understand changes

• Multiple contributions per day is normal

• Contribute whenever you complete a logical unit of work

• No limit on number of contributions

• Track incremental progress

• Enable rollback if needed

• Document decision trail

• Support collaboration

When to Contribute

• You've completed a logical change

• You want to save your progress

• You're done for the day

• You want others to see your work

• You're switching to a different task

• Don't save up days of work before contributing

• Don't wait until "everything is perfect"

• Don't skip contributions to keep history "clean"

Understanding Revisions

What is a Revision?

Revision Naming Convention

• Significant design changes

• New functionality or major modifications

• Changes affecting fit, form, or function

• Typically require re-review or re-approval

• Small updates within a major revision

• Corrections or refinements

• Changes that don't affect major characteristics

• May not require full re-review

Rev A → First complete design
Rev A.1 → Minor corrections after review
Rev A.2 → Drawing updates, no part changes
Rev B → Major redesign for manufacturing
Rev B.1 → Supplier-requested modifications
Rev C → Cost reduction changes

When to Create a Revision

• Concept review complete

• Preliminary design review (PDR)

• Critical design review (CDR)

• First article inspection (FAI)

• Released to manufacturing

• Sent to supplier for quote

• Tooling design complete

• Production release

• Prototype delivery

• Production units

• Field updates

• Custom configurations

• FDA submission

• CE marking documentation

• Patent applications

• Safety certifications

• Major geometry modifications

• Material changes

• Assembly structure changes

• Performance improvements

Revision Lifecycle

Rev - (dash) → Initial development, not yet Rev A
Rev A → First formal release
Rev A.1 → Minor update
Rev A.2 → Another minor update
Rev B → Major change requiring new major revision
Rev B.1 → Minor update to Rev B
Rev C → Next major change

Understanding Releases

What is a Release?

Release Types

• Approved for production

• Suppliers can begin tooling

• Manufacturing can proceed

• Quality inspections based on this version

• Approved for prototype build

• May have known issues to be resolved

• Used for testing and validation

• Approved for shipment to customer

• Meets all requirements

• Documentation complete

• Approved for FDA, CE, or other regulatory filing

• Complete documentation package

• Traceable configuration

• No longer valid for new production

• Superseded by newer revision

• Historical record only

Release Control

• Typically requires Admin role

• May require ECO approval first

• Often tied to formal review process

1. Design reaches milestone (e.g., Rev B)

2. ECO created to request release

3. Stakeholders review and approve

4. Admin promotes revision to "Released" status

5. Manufacturing/customers notified

6. Released version is locked (changes require new revision)

Contributions vs. Revisions vs. Releases

Comparison Table

Visual Hierarchy

Project: Hydraulic Pump
│
├── Contributions (many)
│   ├── d27710: "Updated housing geometry"
│   ├── d96d47: "Fixed interference"
│   ├── f5cc92: "Adjusted tolerances"
│   ├── a1b2c3: "Final for Rev A" ← Marked as Rev A
│   ├── d4e5f6: "Drawing corrections"
│   ├── g7h8i9: "Minor updates" ← Marked as Rev A.1
│   ├── j1k2l3: "Major redesign start"
│   └── m4n5o6: "Redesign complete" ← Marked as Rev B, Released for Manufacturing
│
├── Revisions (formal labels)
│   ├── Rev A (commit a1b2c3)
│   ├── Rev A.1 (commit g7h8i9)
│   └── Rev B (commit m4n5o6) ← Released
│
└── Releases (controlled versions)
    └── Rev B - Released for Manufacturing

Revision Naming Best Practices

Standard Naming Conventions

• A, B, C, D... (most common)

• Clear progression

• Universally understood

• Skips letters that look like numbers (I, O, Q sometimes)

• A.1, A.2, A.3...

• B.1, B.2, B.3...

• Decimal notation is standard

• Some companies use: 1, 2, 3 for major, 1.1, 1.2 for minor

• Automotive often uses: A, B, C with numeric suffixes

• Aerospace may have company-specific schemes

When to Increment

• Significant geometry changes

• Material or process changes

• Changes affecting interchangeability

• New functionality

• Manufacturing method changes

• Drawing corrections (no part change)

• Dimension tolerance adjustments

• Surface finish changes

• Documentation updates

• Minor geometry tweaks not affecting fit

• Work in progress

• Development iterations

• Exploratory changes

• Pre-release modifications

Release Management Workflow

Workflow 1: Simple Release (Small Team)

1. Engineer completes design → Contributes as "Final for Rev A"

2. Project lead reviews → Approves

3. Admin marks Rev A as "Released for Manufacturing"

4. Manufacturing begins production

Workflow 2: ECO-Based Release (Formal Process)

1. Engineer completes design → Contributes as "Ready for Rev B release"

2. Engineer creates ECO requesting release of Rev B

3. Multi-discipline review:
• Design engineer verifies completeness
• Manufacturing engineer verifies producibility
• Quality engineer verifies compliance
• Project manager verifies schedule/budget

4. All reviewers approve ECO

5. Admin promotes Rev B to "Released for Manufacturing"

6. ECO closed with release documentation

7. Stakeholders notified

Workflow 3: Customer Approval Release

1. Engineer completes design → Rev A

2. Internal review and approval

3. Rev A sent to customer for review (guest access)

4. Customer provides feedback → Engineer makes changes

5. Rev A.1 incorporates customer feedback

6. Customer approves Rev A.1

7. Admin releases Rev A.1 for Customer Delivery

8. Manufacturing proceeds

Best Practices

Contribution Best Practices

• Describe what changed, not what you did

• ✅ "Increased wall thickness to 3mm per stress analysis"

• ❌ "Updated file"

• Multiple times per day during active work

• Whenever you complete a logical change

• Before switching tasks or ending the day

• Use staging to contribute multiple files together

• One contribution for one logical change

• Example: Contribute part and assembly together if both changed

Revision Best Practices

• Define what constitutes a major vs. minor revision

• Document your revision policy

• Train team on when to create revisions

• Use the same scheme across all projects

• Don't mix alphabetic and numeric major revisions

• Document your naming convention

• Tie revisions to project milestones

• Rev A = Prototype, Rev B = Production, etc.

• Makes progression clear

• Maintain revision history table in drawings

• List what changed in each revision

• Reference ECOs if applicable

Release Best Practices

• Require ECO approval before releasing

• Document who approved and why

• Maintain approval records

• Define what "released" means

• Specify release types (manufacturing, customer, etc.)

• Document release authority

• Notify stakeholders when releases happen

• Manufacturing needs to know immediately

• Customers need formal notification

• Changes to released versions require new revision

• Prevents unauthorized modifications

• Maintains traceability

Revision History Documentation

Revision Table

CAD ROOMS Integration

• All contributions tracked with commit hashes

• Revision labels linked to specific contributions

• Release status documented

• ECOs linked to revisions

• Export activity log

• Filter by revision labels

• Include in documentation packages

Regulatory and Compliance

FDA (Medical Devices)

• Design History File (DHF) with all revisions

• Traceability from requirements to design to production

• Change control documentation

• Approval records

• Complete contribution history = DHF

• Revisions mark design milestones

• ECOs provide change control

• Releases document approval

AS9100 (Aerospace)

• Configuration management

• Design change control

• Approval documentation

• Traceability

• Revisions provide configuration control

• ECOs manage design changes

• Releases document approvals

• Audit trail maintained

IATF 16949 (Automotive)

• PPAP documentation

• Engineering change management

• Customer approval for changes

• Traceability to production

• Revisions support PPAP

• ECOs manage engineering changes

• Guest access enables customer approval

• Releases link to production

Common Scenarios

Scenario 1: First Production Release

1. Engineer contributes final changes with message "Ready for Rev A release"

2. Create ECO requesting Rev A release for manufacturing

3. Team reviews design completeness

4. Manufacturing reviews producibility

5. Quality reviews compliance

6. All approve ECO

7. Admin marks Rev A as "Released for Manufacturing"

8. Manufacturing receives notification and begins production

Scenario 2: Field Issue Correction

1. Quality creates ECO describing field issue and proposed fix

2. Engineer implements fix, contributes changes

3. Testing validates fix

4. ECO approved

5. Admin creates Rev B.1 (minor revision for field fix)

6. Rev B.1 released for manufacturing

7. Field units updated, new production uses Rev B.1

Scenario 3: Customer-Requested Change

1. Sales creates ECO with customer request

2. Engineering evaluates feasibility

3. Customer approves proposed solution (guest access to ECO)

4. Engineer implements, contributes changes

5. Admin creates Rev C (major revision for customer change)

6. Rev C released for customer delivery

7. Customer receives Rev C units

Scenario 4: Cost Reduction

1. Manufacturing creates ECO proposing material change

2. Engineering reviews performance impact

3. Quality reviews compliance

4. Testing validates new material

5. ECO approved

6. Engineer updates design, contributes changes

7. Admin creates Rev B (major revision for material change)

8. Rev B released for manufacturing

9. Old revision (Rev A) marked obsolete

Troubleshooting

Problem: Too Many Revisions

• Use contributions for development iterations

• Create revisions only at formal milestones

• Rev A should be first production release, not first draft

Problem: Unclear Revision Progression

• Maintain revision history table

• Link revisions to ECOs

• Document reason for each revision

Problem: Released Version Modified

• Implement ECO requirement for released versions

• Train team that released = locked

• Use permissions to prevent unauthorized changes

Problem: Revision Naming Inconsistency

• Document company revision naming standard

• Train team on standard

• Enforce consistency in reviews

Quick Reference

When to Create What

Revision Increment Guide

Next Steps

1. Define your revision policy - When to create major vs. minor revisions

2. Document your naming convention - Ensure consistency across projects

3. Implement release workflow - ECO-based or simplified

4. Train your team - When to contribute vs. create revisions

5. Start using revisions - Mark your next milestone as Rev A

• Understanding Version Control in CAD ROOMS

• Understanding Engineering Change Orders

• File Release Management

• Engineering Change Orders (task guide)

• Audit Logs