Home / Courses / Engineering Graphics and CAD / Lesson 29

Engineering Graphics and CAD · Lesson 29 of 35

Revisions, versions, and engineering change

Manage change to models and drawings with versions, revisions, and a change process.

Readiness check

Learning objectives

By the end of this lesson you can:

Distinguish version history from released revisions.
Record a revision with a revision block and note.
Follow an engineering change request and notice flow at an introductory level.
Use branching and version history to explore changes safely.
Explain why traceability matters.

Check your starting point

Five to ten minutes.

Is every save of a CAD model a formal revision, or something less formal?
If a released drawing must change, what should record what changed and why?
How could you try a design change without risking the current working design?

Interpretation.

Q1: Something less formal; saves and versions are continuous, while a revision is a controlled, documented release. Skill 29.1.
Q2: A revision block and note (and a change record). Skill 29.2.
Q3: On a branch or a saved version, so the main design is safe. Skill 29.4.

You need L28 (drawings to revise).

0 or 1 weak itemsContinue with this lesson.

2 weak itemsReview Lesson 28, then return.

3 or more weak itemsWork through the prerequisite examples before continuing.

The core idea

What it is. Managing change means handling how models and drawings evolve: keeping a continuous version history, issuing controlled revisions of released drawings, and following an engineering change process, all with traceability (a record of what changed, when, and why).

Why an engineer needs it. Designs change constantly, and other people depend on knowing which version is current and what changed. Without disciplined change management, teams build to outdated drawings, lose track of decisions, and cannot reproduce a design. Traceability is what lets an engineering decision be trusted and reconstructed later.

What problem it solves. It keeps the documentation trustworthy over time: everyone knows the current revision, what changed, and why, and changes can be explored safely.

What goes wrong when it is ignored. Overwriting a released drawing with no record, or working on the same design as others without version control, leads to lost work, parts built to old drawings, and untraceable decisions.

A simple mechanical example. The bearing-block drawing is released. Later, a tolerance must be loosened. Instead of silently editing it, you record a revision (say revision B), note the change and reason in the revision block, and keep the history so anyone can see what changed from A to B and why.

Key ideas:

Version history is the continuous, automatic record of saves/versions (in Onshape, a version graph). It is granular and informal.
A revision is a controlled, documented release (revision A, B, C), recorded in a revision block/table with what changed and when.
Engineering change at an introductory level: a change request (ECR) proposes a change with a reason; a change notice (ECN) authorizes and records it.
Branching lets you try a change on a separate branch without disturbing the main design, then merge or release if it is good.
Traceability ties every change to a reason and a record, so decisions can be trusted and reconstructed.

Part 5: Parts, assemblies, and drawings.

Check: explain the decision in your own words before using a CAD command.

The lesson map. Revisions, versions, and engineering change becomes manageable when you move through the four checks in order and verify each result before continuing.

The skills, taught in order

Skill 29.1 - Distinguish versions from revisions

Concept. Versions are continuous and informal; revisions are controlled releases. Terminology. Version history, revision, release. Procedure. Use versions freely as you work; issue a revision only when a released drawing changes in a controlled way. Reasoning. Separating the two keeps everyday work fluid and releases disciplined. Failure mode. Treating every save as a revision, or never recording revisions. Check. State the difference between a version and a revision.

Skill 29.2 - Record a revision

Concept. A revision is documented in a revision block with what changed and when. Terminology. Revision block/table, revision level, change note. Procedure. On a controlled change, increment the revision level, add a revision-block row with the change description and date, and update the drawing. Reasoning. The revision block makes the change visible and traceable. Failure mode. Changing a released drawing without recording the revision. Check. Add a revision-block row for a tolerance change.

Skill 29.3 - Follow an introductory change process

Concept. A change is proposed (request) and authorized/recorded (notice). Terminology. Engineering change request (ECR), engineering change notice (ECN). Procedure. Propose the change with a reason (ECR), get it authorized, and record it (ECN), then implement and revise. Reasoning. A process ensures changes are justified, authorized, and recorded. Failure mode. Making unrecorded, unauthorized changes. Check. State what an ECR and an ECN each do.

Skill 29.4 - Use branching and version history safely

Concept. Branches let you try changes without disturbing the main design. Terminology. Branch, version graph, merge. Procedure. Branch from the current version, make and test the change on the branch, then merge or release if it is good; otherwise discard the branch. Reasoning. Branching isolates experiments and preserves the working design. Failure mode. Editing the main design directly to try a risky change. Check. Describe how to test a change without risking the main design.

Worked example 1: record a revision on the bearing-block drawing

Problem. The released bearing-block drawing (revision A) needs its bore tolerance loosened because the current fit is too tight to assemble. Record the change as revision B.

Planning. Make the controlled change, increment the revision, and document it in the revision block.

Solution.

Reason. The bore fit is too tight to assemble; loosening the tolerance (within function) fixes it. This is the change reason.
Make the change. Update the model's bore tolerance so the fit assembles (verified against L14), which updates the driven dimension on the drawing.
Increment the revision. Move the drawing from revision A to revision B.
Revision block. Add a row: revision B, description "bore tolerance loosened to ease assembly," date, and approver. The change is now recorded.
Release. Issue revision B; anyone comparing A and B sees exactly what changed and why.

Result. The bore tolerance change is recorded as revision B with a dated revision-block note stating the reason, so the change is visible and traceable from revision A.

Why the method works. Incrementing the revision and documenting the change in the revision block makes the change controlled and traceable, not silent.

How to verify independently. Compare revision A and B: the only change is the bore tolerance, and the revision block explains it. A clear, documented difference confirms the revision was recorded properly.

Worked example 2: testing a change on a branch

Problem. You want to try a larger design change (adding a lubrication groove to the bore) without risking the current released design. Use a branch to test it, compare versions, and, if it works, prepare it as a change. The complication is exploring a change safely and documenting the rationale.

Planning. Branch from the current version, make and test the change on the branch, compare, then decide.

Solution.

Branch. Create a branch from the current version of the bearing block. The main (released) design is untouched.
Make the change on the branch. Add the lubrication groove feature to the bore on the branch, and update its drawing.
Test and compare. Check the groove does not break the model (robustness, L23), does not cause interference (L26), and still assembles. Compare the branch version with the main to see exactly what changed.
Decide. If the groove works and is wanted, propose it as an engineering change (ECR with the reason "add lubrication groove for bearing life"), get it authorized (ECN), then merge or release it as the next revision. If it does not work, discard the branch; the main design was never at risk.
Traceability. The branch, the comparison, and the change record together document what was tried, what changed, and why.

Comparison. Editing the main design directly to try the groove would risk the released design; branching isolates the experiment and preserves the working design until the change is proven and authorized. The version graph and change record keep the whole thing traceable.

Result. The lubrication-groove change is developed and tested on a branch, compared with the main, and, if adopted, taken through an ECR/ECN into a new revision; the released design is never put at risk.

Independent check. Confirm the main design is unchanged while the branch carries the groove, and that a comparison shows exactly the groove as the difference. Isolation plus a clear diff confirms safe, traceable change.

Misconceptions and diagnostics

Misconception	Why it seems reasonable	Why it is wrong	Evidence that reveals it	Correction	Diagnostic question
"Every save is a revision."	Saves record changes.	Versions are continuous and informal; a revision is a controlled, documented release.	Hundreds of saves but only a few released revisions.	Use versions freely; issue revisions for controlled releases.	"Is this a controlled release or just a save?"
"Just overwrite the old drawing."	It updates the file.	Overwriting with no record loses traceability and misleads others.	Nobody can tell what changed or why.	Record the revision in the revision block.	"Is the change documented in the revision block?"
"Try risky changes on the main design."	It is the current file.	Editing the main risks the released design; branches isolate experiments.	A failed experiment corrupts the working design.	Branch, test, then merge or discard.	"Am I risking the released design to try this?"

Practice ladder

Level A - Recognition

Task. On a drawing and version graph, identify the current revision, the revision block, and the version history. Deliverable. A labelled example. Success criteria. Revision, revision block, and version history correctly identified. Answer guidance. Revisions are letters/numbers in the block; versions are graph nodes. Common errors. Confusing a version with a revision. Difficulty. Low.

Level B - Guided application

Task. Record a guided revision (given the change) in a revision block. Deliverable. The updated revision block. Success criteria. Correct revision level, description, and date. Answer guidance. Increment the level; note what and why. Common errors. Omitting the reason. Difficulty. Low to medium.

Level C - Independent application

Task. Apply and document a change to your drawing independently, incrementing the revision. Deliverable. The revised drawing with a revision-block entry. Success criteria. Change implemented; revision recorded with reason and date. Answer guidance. Change the model, then document the revision. Common errors. Changing without recording. Difficulty. Medium.

Level D - Transfer and design

Task. Given a change request, execute it on a branch, document the ECR rationale, prepare the revision, and reflect on traceability. Deliverable. The branch change, an ECR note, the prepared revision, and a short reflection. Success criteria. Change isolated on a branch; ECR rationale clear; revision documented; reflection addresses traceability. Answer guidance. Branch, test, propose, authorize, revise. Common errors. Editing the main design directly. Difficulty. Medium to high. (Design-change test evidence; feeds the final project's engineering change.)

Working with AI, and proving it yourself

Use AI as a tutor

Useful AI support:

Ask it to explain version versus revision.
Ask it to draft a revision-block note for a change (then verify it captures what and why).
Ask it to outline an ECR/ECN flow.

Limits:

A text assistant cannot see your version history.
It may blur the version/revision distinction.

Verify AI output against: the version-versus-revision distinction, the revision-block requirement (what and why), and safe branching.

Prove it yourself

A plausible but incorrect AI answer, and how to catch it. You ask, "I fixed a tolerance on the released drawing. Do I need to record anything, or just save it?" and the assistant replies: "Just save it; the file now has the correct value, so no record is needed."

This loses traceability. Detect it with the revision principle: a released drawing is a controlled document, so a change must be recorded as a revision with what changed and why, or others cannot tell the drawing changed. The evidence is a downstream user building to the old revision, unaware. Correct conclusion: increment the revision, document it in the revision block, and release it; do not silently overwrite.

Retrieval and spaced review

What is the difference between a version and a revision?
What does a revision block record?
What do an ECR and an ECN do?
Why use a branch for a risky change?
What is traceability, and why does it matter?
Why not silently overwrite a released drawing?
Cumulative (L28): When you revise a model, why does the driven drawing update, and what must you still record?
Reconstruction task: From memory, describe recording the bore-tolerance change as revision B.

Answers. 1: a version is a continuous, informal save point; a revision is a controlled, documented release. 2: the revision level, what changed, when, and by whom. 3: an ECR proposes a change with a reason; an ECN authorizes and records it. 4: to isolate the experiment so the released design is not at risk. 5: the recorded chain of what changed and why, so decisions can be trusted and reconstructed. 6: it loses traceability and lets others build to an outdated drawing. 7: the drawing is associative so it updates automatically, but you must still record the revision (what and why).

Suggested review intervals. 1 day, 3 days, 7 days.

Reference mapping and next step

Read further

Onshape docs (versions, releases)
Giesecke ch.14.

Standards details must be checked against the current official edition used by your institution or employer.

Finish the lesson

You can now: distinguish versions from revisions; record a revision with a note; follow an introductory change process; use branching safely; and explain traceability.

Self-assessment checklist.

I use versions for work and revisions for releases.
I record every released change in the revision block.
I know what an ECR and ECN do.
I test risky changes on a branch.
I keep my changes traceable.

Next lesson: L30 - Modelling machined parts and connecting CAD to processes (Part VI begins). Why it follows: you can now model, assemble, document, and revise. Part VI turns modelling skill into manufacturing judgement, starting with modelling parts the way they are actually machined and connecting geometry to processes.

Required files or submissions: submit your Level C revised drawing; the final project will require a documented engineering change built on this lesson. Optional extension: in Onshape, create a version, branch it, make a change, and compare the branch with the main.

End of Part V (L24-L29). Part VI (Manufacturability and engineering judgement) begins with L30-L35 in 18-part6-lessons.md, concluding with the final integrated project.

# Engineering Graphics and CAD - Phase 4: Full Lesson Content, Part VI (Manufacturability and Engineering Judgement), L30-L32

Lessons L30-L35 make up Part VI. This file holds L30 (modelling machined parts and connecting CAD to processes), L31 (sheet-metal and fabricated parts, introduction), and L32 (additive-manufacturing considerations). L33-L35 (design for assembly, engineering review, and the final integrated project) are in 19-part6-lessons-cont.md. Process-specific values (drill-point angle, self-supporting angle, K-factor) are given as typical and flagged as process- and material-dependent. No em dashes.