Bug Report: project_open Tcl Command Resets Current Revision to Base Revision in Quartus

Good write-up — let me clarify what's actually happening here based on the documented API behavior, because it explains both the default you're seeing and points to the right mitigations.

Why bare project_open picks the base revision in the shell

This is documented behavior for the ::quartus::project package (the one loaded in quartus_sh). When the -revision option is not specified, the project name is specified as the revision name. project_open (::quartus::project) So a bare project_open my_project will always open the revision whose name matches the project name — it does not look up whatever is marked as the "current revision" in the .qpf unless you tell it to.

Why the GUI behaves differently

The GUI uses a separate Tcl package: ::quartus::project_ui. Its project_open variant has a different option set — notably it includes -error_on_incompatible_database instead of -force, and it by default opens the project and overwrites the database created in a different version of Quartus Prime software project_open (::quartus::project_ui) — and internally the GUI application layer likely passes -current_revision when loading a project from the File menu. The shell executable doesn't do that automatically; you have to be explicit.

The .qpf mutation / revision ordering side-effect

The ::quartus::project package does document a related behavior: the -preserve_revision_order option prevents moving the revision to the top of the .qpf file and preserves existing revision ordering. project_open (::quartus::project) If you open without this flag, the shell can reorder revisions in the .qpf, which is likely the mechanism behind the "active revision reverts" symptom you're seeing after a shell session.

Recommended pattern for scripted workflows

Use both -current_revision and -preserve_revision_order together in any automation script that isn't explicitly switching revisions:

project_open -current_revision -preserve_revision_order /path/to/my_project.qpf

For scripts that need to be robust about which revision they operate on, the documented full-featured pattern is:

package require cmdline
variable ::argv0 $::quartus(args)
set options { \
  { "project.arg" "" "Project Name" } \
  { "revision.arg" "" "Revision Name" } \
}
array set optshash [::cmdline::getoptions ::argv0 $options]
if {[project_exists $optshash(project)]} {
  if {[string equal "" $optshash(revision)]} {
    project_open $optshash(project) -current_revision
  } else {
    project_open $optshash(project) -revision $optshash(revision)
  }
} else {
  puts "Project $optshash(project) does not exist"
  exit 1
}

Bottom line: The default-to-project-name behavior is by design in the ::quartus::project package, not a regression. The discrepancy with the GUI is real — the GUI internally uses -current_revision — but it is the result of the two packages (::quartus::project vs ::quartus::project_ui) having different defaults, not a bug in either path per se. The fix for your hybrid workflows is straightforward: always pass -current_revision -preserve_revision_order in your shell scripts unless you intentionally want a specific revision by name.

If you believe the default behavior of the shell package should be changed to match the GUI, that's a valid product feedback item worth raising through the official support channel as an enhancement request.

Note: To continue using AI Responder, please start your next inquiry with ai_responder

Disclaimer (Beta): The AI Responder is currently provided as a beta feature. AI-generated responses may contain errors or omissions. Please verify technical guidance with official Altera documentation before implementation.

Thank you very much.