Skip to content

Commit 766bc53

Browse files
author
Aaron Sun
committed
Created spec for issue #2165
1 parent cdbea09 commit 766bc53

File tree

1 file changed

+51
-0
lines changed
  • .specify/features/git-extension-deprecation-notice

1 file changed

+51
-0
lines changed
Lines changed: 51 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,51 @@
1+
# Add notice that git extension will no longer be enabled by default at 1.0.0
2+
3+
> **Source**: [#2165](https://github.com/github/spec-kit/issues/2165) — imported on 2026-04-12
4+
5+
## Overview
6+
7+
Add a deprecation notice during `specify init` to inform users that the git extension, currently auto-enabled by default, will require explicit opt-in starting with v1.0.0. This ensures users are aware of the upcoming behavioral change well in advance.
8+
9+
## Problem Statement
10+
11+
The `git` extension is currently bundled and enabled by default during `specify init`. Starting with v1.0.0, it will still be bundled but no longer enabled by default — users will need to explicitly opt in. Without advance notice, users may be surprised by this change when upgrading to v1.0.0.
12+
13+
## Requirements
14+
15+
### Functional Requirements
16+
17+
- FR-1: During `specify init`, display a warning notice when the git extension is auto-enabled
18+
- FR-2: The notice must clearly state the timeline (v1.0.0) for the change
19+
- FR-3: The notice must explain how to opt in after the change (`specify init --extension git` or `specify extension add git`)
20+
- FR-4: The notice must be non-blocking (warning styling, does not halt initialization)
21+
22+
### Non-Functional Requirements
23+
24+
- NFR-1: Notice should use yellow/warning styling consistent with existing CLI warning patterns
25+
- NFR-2: Notice should be concise and actionable
26+
27+
## User Scenarios
28+
29+
### Scenario 1: User runs specify init and sees deprecation notice
30+
31+
**Given** a user is initializing a new project with `specify init`
32+
**When** the git extension is auto-enabled as part of the default behavior
33+
**Then** a warning notice is displayed informing them that the git extension will require explicit opt-in starting with v1.0.0
34+
35+
### Scenario 2: User understands how to opt in after v1.0.0
36+
37+
**Given** a user sees the deprecation notice during `specify init`
38+
**When** they read the notice
39+
**Then** they understand they can use `specify init --extension git` or `specify extension add git` to enable the git extension after v1.0.0
40+
41+
## Acceptance Criteria
42+
43+
- [ ] AC-1: `specify init` shows a notice when the git extension is auto-enabled
44+
- [ ] AC-2: Notice is visible but non-blocking (yellow/warning styling)
45+
- [ ] AC-3: Message clearly states the timeline (v1.0.0) and how to opt in
46+
47+
## Out of Scope
48+
49+
- Changes to the git extension itself or its functionality
50+
- Changes to the bundled status of the git extension (it remains bundled/shipped with spec-kit)
51+
- Actually removing the default-enabled behavior (that happens at v1.0.0, not now)

0 commit comments

Comments
 (0)