ci: pin the first release to 0.1.0 and scope its changelog - #64

Merged
nadeem4 merged 1 commit into
mainfrom
ci/pin-first-release-to-0-1-0
Aug 28, 2026
Merged

ci: pin the first release to 0.1.0 and scope its changelog#64
nadeem4 merged 1 commit into
mainfrom
ci/pin-first-release-to-0-1-0

Conversation

@nadeem4

@nadeem4nadeem4 commented Aug 28, 2026

Copy link
Copy Markdown
Owner

Release PR #61 (chore: release main) is not mergeable as intended. Two defects, both observed on it.

Defect 1 — it proposes 1.0.0, not 0.1.0

Task 10 landed as refactor!: collapse distribution to .... The ! marks a breaking change, so release-please bumps MAJOR. The generated changelog header reads:

## [1.0.0](https://github.com/nadeem4/nl2sql/compare/v0.1.0...v1.0.0)
### ⚠ BREAKING CHANGES
* collapse distribution to nl2sql, nl2sql-api, nl2sql-adapter-sdk

The plan calls for a 0.1.0 beta, and the maintainer has confirmed 0.1.0.

Defect 2 — the changelog is the entire repository history

It contains 228 entries — every feat: ever committed (e.g. "add AggregatorNode", "Add CLI for NL2SQL LangGraph pipeline"), including many predating this work, several duplicated.

There are zero tags in the repo (verified local and remote), so release-please has no baseline and walks all history. Note the compare URL above references a v0.1.0 tag that does not exist.

The three knobs

Each was verified against googleapis/release-pleasedocs/manifest-releaser.md, README.md and schemas/config.json before being applied.

bump-minor-pre-major: true — top-level

Schema description (definitions.ReleaserConfigOptions.properties):

Breaking changes only bump semver minor if version < 1.0.0

So while the version is below 1.0.0 a feat!/fix! moves 0.1.0 to 0.2.0, which is semver's rule for a pre-1.0 public API. Without it the next breaking commit lands on 1.0.0 by accident — which is precisely defect 1.

Valid both top-level and per-package (the root schema allOf-inherits ReleaserConfigOptions). Placed top-level, where it is the default for the single package.

bootstrap-sha — top-level (top-level only)

You can add a top level "bootstrap-sha": <full sha value> key/value entry to the config which will cause release-please to stop there for collecting changelog commits (so choose one commit earlier than the first commit you want to include).

and

  • full sha required.
  • only applicable at top-level config.

Set to 39d488ae9f9943ea5d9879bf2dd503c34370b24a. That is the parent of 28687fe (merge of PR #47, Phase 1 Task 1, chore: stop tracking runtime and build artifacts), so Task 1 itself is included and the changelog covers this phase rather than the whole project.

It is self-expiring:

Note: once a release-please generated PR has been merged, this config value will be ignored for all subsequent runs and can be removed.

bootstrap-sha is present in the root properties allowlist but absent from ReleaserConfigOptions, confirming it cannot go per-package.

Release-As: 0.1.0 — a commit footer, not a config key

This is the one that needed care. release-as in the config is sticky. From docs/manifest-releaser.md, immediately above the "release-as" example:

Note: once the release PR is merged you should either remove this or update it to a higher version. Otherwise subsequent manifest-pr runs will continue to use this version even though it was already set in the last release.

It does not pin one release — it pins every release, forever, to that version, silently. The schema also marks the per-package form deprecated:

[DEPRECATED] Override the next version of this package. Consider using a Release-As commit instead.

So no release-as key was added to release-please-config.json. The version is pinned by a commit footer instead, per README.md:

When a commit to the main branch has Release-As: x.x.x (case insensitive) in the commit body, Release Please will open a new pull request for the specified version.

The commit on this branch carries Release-As: 0.1.0 in its body. The footer applies to that one commit and expires with it, so there is nothing to remember to remove — which is the whole reason it was chosen over the config key. This repo merges PRs with merge commits, so the footer reaches main intact.

Changes

Only two files. CHANGELOG.md, every version number and .release-please-manifest.json are untouched.

release-please-config.json — two lines:

{
"$schema": "https://raw.githubusercontent.com/googleapis/release-please/main/schemas/config.json",
"release-type": "python",
"bootstrap-sha": "39d488ae9f9943ea5d9879bf2dd503c34370b24a",
"bump-minor-pre-major": true,
"separate-pull-requests": false,
"include-component-in-tag": false,
"packages": { ... }
}

docs/development/releasing.md — documents the pre-1.0 bump rule, what bootstrap-sha does and that it can be dropped once a real tag exists, and a !!! danger admonition on the sticky release-as config key explaining why this repo uses the footer instead and should not gain that key.

Verification

  • release-please-config.json parses as JSON.
  • git cat-file -t 39d488ae9f... → commit; git rev-parse 28687fe^ → 39d488ae9f9943ea5d9879bf2dd503c34370b24a (exact match).
  • Unit pytest -m "not integration": 231 passed, 1 skipped, 47 deselected — twice, unchanged.
  • Key-free integration pytest -m "integration and not llm": 28 passed — twice, unchanged.
  • mkdocs build --strict clean (exit 0, no warnings), throwaway venv from requirements-docs.txt.

Nothing was tagged, published or released.

After merge, release-please will regenerate PR #61 — the version and changelog can be verified there.

@nadeem4
ci: pin the first release to 0.1.0 and scope its changelog
f8d3137
release-please opened its first release PR proposing 1.0.0 with a changelog
containing 228 entries covering the entire history of the repository.
Two causes, two fixes:
The `refactor!:` that collapsed the distributions is a breaking change, so
release-please bumped MAJOR. `bump-minor-pre-major: true` applies semver's
pre-1.0 rule instead, so a breaking change moves 0.x to 0.(x+1) rather than
to 1.0.0. Placed top-level, where it is the default for every package.
There are no tags in the repository, so release-please had no baseline and
walked all history. `bootstrap-sha` stops the commit scan at 39d488a, the
parent of 28687fe (the first PR of this phase), so the changelog covers this
phase. It is top-level because the schema does not accept it per-package. It
is ignored once a release PR has merged and can be removed then.
The version itself is pinned by the footer below rather than by a `release-as`
config key: that key is sticky and would pin every subsequent release to
0.1.0, and the schema marks the per-package form deprecated in favour of the
commit footer. The footer expires with this commit, so there is nothing to
remember to remove.
Release-As: 0.1.0
@nadeem4
nadeem4 merged commit ea9106b into mainAug 28, 2026
8 checks passed
@nadeem4
nadeem4 deleted the ci/pin-first-release-to-0-1-0 branch August 28, 2026 14:30
@nadeem4nadeem4 mentioned this pull request Sep 1, 2026
Open
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@nadeem4
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all 
 blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks");
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '

Skip to content
ci: pin the first release to 0.1.0 and scope its changelog - #64
Merged
nadeem4 merged 1 commit into
mainfrom 
ci/pin-first-release-to-0-1-0
Aug 28, 2026
Merged
ci: pin the first release to 0.1.0 and scope its changelog#64
nadeem4 merged 1 commit into
mainfrom 
ci/pin-first-release-to-0-1-0
Conversation
@nadeem4
@nadeem4nadeem4
commented
Aug 28, 2026

Copy link


Copy Markdown

Owner
Release PR #61 (chore: release main) is not mergeable as intended. Two defects, both observed on it.
Defect 1 — it proposes 1.0.0, not 0.1.0
Task 10 landed as refactor!: collapse distribution to .... The ! marks a breaking change, so release-please bumps MAJOR. The generated changelog header reads:
## [1.0.0](https://github.com/nadeem4/nl2sql/compare/v0.1.0...v1.0.0)
### ⚠ BREAKING CHANGES
* collapse distribution to nl2sql, nl2sql-api, nl2sql-adapter-sdk

The plan calls for a 0.1.0 beta, and the maintainer has confirmed 0.1.0.
Defect 2 — the changelog is the entire repository history
It contains 228 entries — every feat: ever committed (e.g. "add AggregatorNode", "Add CLI for NL2SQL LangGraph pipeline"), including many predating this work, several duplicated.
There are zero tags in the repo (verified local and remote), so release-please has no baseline and walks all history. Note the compare URL above references a v0.1.0 tag that does not exist.
The three knobs
Each was verified against googleapis/release-pleasedocs/manifest-releaser.md, README.md and schemas/config.json before being applied.
bump-minor-pre-major: true — top-level
Schema description (definitions.ReleaserConfigOptions.properties):
Breaking changes only bump semver minor if version < 1.0.0
So while the version is below 1.0.0 a feat!/fix! moves 0.1.0 to 0.2.0, which is semver's rule for a pre-1.0 public API. Without it the next breaking commit lands on 1.0.0 by accident — which is precisely defect 1.
Valid both top-level and per-package (the root schema allOf-inherits ReleaserConfigOptions). Placed top-level, where it is the default for the single package.
bootstrap-sha — top-level (top-level only)
You can add a top level "bootstrap-sha": <full sha value> key/value entry to the config which will cause release-please to stop there for collecting changelog commits (so choose one commit earlier than the first commit you want to include).
and
  • full sha required.
  • only applicable at top-level config.
Set to 39d488ae9f9943ea5d9879bf2dd503c34370b24a. That is the parent of 28687fe (merge of PR #47, Phase 1 Task 1, chore: stop tracking runtime and build artifacts), so Task 1 itself is included and the changelog covers this phase rather than the whole project.
It is self-expiring:
Note: once a release-please generated PR has been merged, this config value will be ignored for all subsequent runs and can be removed.
bootstrap-sha is present in the root properties allowlist but absent from ReleaserConfigOptions, confirming it cannot go per-package.
Release-As: 0.1.0 — a commit footer, not a config key
This is the one that needed care. release-as in the config is sticky. From docs/manifest-releaser.md, immediately above the "release-as" example:
Note: once the release PR is merged you should either remove this or update it to a higher version. Otherwise subsequent manifest-pr runs will continue to use this version even though it was already set in the last release.
It does not pin one release — it pins every release, forever, to that version, silently. The schema also marks the per-package form deprecated:
[DEPRECATED] Override the next version of this package. Consider using a Release-As commit instead.
So no release-as key was added to release-please-config.json. The version is pinned by a commit footer instead, per README.md:
When a commit to the main branch has Release-As: x.x.x (case insensitive) in the commit body, Release Please will open a new pull request for the specified version.
The commit on this branch carries Release-As: 0.1.0 in its body. The footer applies to that one commit and expires with it, so there is nothing to remember to remove — which is the whole reason it was chosen over the config key. This repo merges PRs with merge commits, so the footer reaches main intact.
Changes
Only two files. CHANGELOG.md, every version number and .release-please-manifest.json are untouched.
release-please-config.json — two lines:
{
"$schema": "https://raw.githubusercontent.com/googleapis/release-please/main/schemas/config.json",
"release-type": "python",
"bootstrap-sha": "39d488ae9f9943ea5d9879bf2dd503c34370b24a",
"bump-minor-pre-major": true,
"separate-pull-requests": false,
"include-component-in-tag": false,
"packages": { ... }
}
docs/development/releasing.md — documents the pre-1.0 bump rule, what bootstrap-sha does and that it can be dropped once a real tag exists, and a !!! danger admonition on the sticky release-as config key explaining why this repo uses the footer instead and should not gain that key.
Verification
  • release-please-config.json parses as JSON.
  • git cat-file -t 39d488ae9f... → commit; git rev-parse 28687fe^ → 39d488ae9f9943ea5d9879bf2dd503c34370b24a (exact match).
  • Unit pytest -m "not integration": 231 passed, 1 skipped, 47 deselected — twice, unchanged.
  • Key-free integration pytest -m "integration and not llm": 28 passed — twice, unchanged.
  • mkdocs build --strict clean (exit 0, no warnings), throwaway venv from requirements-docs.txt.
Nothing was tagged, published or released.
After merge, release-please will regenerate PR #61 — the version and changelog can be verified there.
@nadeem4
ci: pin the first release to 0.1.0 and scope its changelog
f8d3137
release-please opened its first release PR proposing 1.0.0 with a changelog
containing 228 entries covering the entire history of the repository.
Two causes, two fixes:
The `refactor!:` that collapsed the distributions is a breaking change, so
release-please bumped MAJOR. `bump-minor-pre-major: true` applies semver's
pre-1.0 rule instead, so a breaking change moves 0.x to 0.(x+1) rather than
to 1.0.0. Placed top-level, where it is the default for every package.
There are no tags in the repository, so release-please had no baseline and
walked all history. `bootstrap-sha` stops the commit scan at 39d488a, the
parent of 28687fe (the first PR of this phase), so the changelog covers this
phase. It is top-level because the schema does not accept it per-package. It
is ignored once a release PR has merged and can be removed then.
The version itself is pinned by the footer below rather than by a `release-as`
config key: that key is sticky and would pin every subsequent release to
0.1.0, and the schema marks the per-package form deprecated in favour of the
commit footer. The footer expires with this commit, so there is nothing to
remember to remove.
Release-As: 0.1.0
@nadeem4
nadeem4
merged commit ea9106b
into
mainAug 28, 2026

8 checks passed

@nadeem4
nadeem4
deleted the

ci/pin-first-release-to-0-1-0

branch
August 28, 2026 14:30
@nadeem4nadeem4
mentioned this pull request
Sep 1, 2026
 Open

Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


No reviews


Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

1 participant

@nadeem4

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix");
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
ci: pin the first release to 0.1.0 and scope its changelog - #64
Merged
nadeem4 merged 1 commit into
mainfrom 
ci/pin-first-release-to-0-1-0
Aug 28, 2026
Merged
ci: pin the first release to 0.1.0 and scope its changelog#64
nadeem4 merged 1 commit into
mainfrom 
ci/pin-first-release-to-0-1-0
Conversation
@nadeem4
@nadeem4nadeem4
commented
Aug 28, 2026

Copy link


Copy Markdown

Owner
Release PR #61 (chore: release main) is not mergeable as intended. Two defects, both observed on it.
Defect 1 — it proposes 1.0.0, not 0.1.0
Task 10 landed as refactor!: collapse distribution to .... The ! marks a breaking change, so release-please bumps MAJOR. The generated changelog header reads:
## [1.0.0](https://github.com/nadeem4/nl2sql/compare/v0.1.0...v1.0.0)
### ⚠ BREAKING CHANGES
* collapse distribution to nl2sql, nl2sql-api, nl2sql-adapter-sdk

The plan calls for a 0.1.0 beta, and the maintainer has confirmed 0.1.0.
Defect 2 — the changelog is the entire repository history
It contains 228 entries — every feat: ever committed (e.g. "add AggregatorNode", "Add CLI for NL2SQL LangGraph pipeline"), including many predating this work, several duplicated.
There are zero tags in the repo (verified local and remote), so release-please has no baseline and walks all history. Note the compare URL above references a v0.1.0 tag that does not exist.
The three knobs
Each was verified against googleapis/release-pleasedocs/manifest-releaser.md, README.md and schemas/config.json before being applied.
bump-minor-pre-major: true — top-level
Schema description (definitions.ReleaserConfigOptions.properties):
Breaking changes only bump semver minor if version < 1.0.0
So while the version is below 1.0.0 a feat!/fix! moves 0.1.0 to 0.2.0, which is semver's rule for a pre-1.0 public API. Without it the next breaking commit lands on 1.0.0 by accident — which is precisely defect 1.
Valid both top-level and per-package (the root schema allOf-inherits ReleaserConfigOptions). Placed top-level, where it is the default for the single package.
bootstrap-sha — top-level (top-level only)
You can add a top level "bootstrap-sha": <full sha value> key/value entry to the config which will cause release-please to stop there for collecting changelog commits (so choose one commit earlier than the first commit you want to include).
and
  • full sha required.
  • only applicable at top-level config.
Set to 39d488ae9f9943ea5d9879bf2dd503c34370b24a. That is the parent of 28687fe (merge of PR #47, Phase 1 Task 1, chore: stop tracking runtime and build artifacts), so Task 1 itself is included and the changelog covers this phase rather than the whole project.
It is self-expiring:
Note: once a release-please generated PR has been merged, this config value will be ignored for all subsequent runs and can be removed.
bootstrap-sha is present in the root properties allowlist but absent from ReleaserConfigOptions, confirming it cannot go per-package.
Release-As: 0.1.0 — a commit footer, not a config key
This is the one that needed care. release-as in the config is sticky. From docs/manifest-releaser.md, immediately above the "release-as" example:
Note: once the release PR is merged you should either remove this or update it to a higher version. Otherwise subsequent manifest-pr runs will continue to use this version even though it was already set in the last release.
It does not pin one release — it pins every release, forever, to that version, silently. The schema also marks the per-package form deprecated:
[DEPRECATED] Override the next version of this package. Consider using a Release-As commit instead.
So no release-as key was added to release-please-config.json. The version is pinned by a commit footer instead, per README.md:
When a commit to the main branch has Release-As: x.x.x (case insensitive) in the commit body, Release Please will open a new pull request for the specified version.
The commit on this branch carries Release-As: 0.1.0 in its body. The footer applies to that one commit and expires with it, so there is nothing to remember to remove — which is the whole reason it was chosen over the config key. This repo merges PRs with merge commits, so the footer reaches main intact.
Changes
Only two files. CHANGELOG.md, every version number and .release-please-manifest.json are untouched.
release-please-config.json — two lines:
{
"$schema": "https://raw.githubusercontent.com/googleapis/release-please/main/schemas/config.json",
"release-type": "python",
"bootstrap-sha": "39d488ae9f9943ea5d9879bf2dd503c34370b24a",
"bump-minor-pre-major": true,
"separate-pull-requests": false,
"include-component-in-tag": false,
"packages": { ... }
}
docs/development/releasing.md — documents the pre-1.0 bump rule, what bootstrap-sha does and that it can be dropped once a real tag exists, and a !!! danger admonition on the sticky release-as config key explaining why this repo uses the footer instead and should not gain that key.
Verification
  • release-please-config.json parses as JSON.
  • git cat-file -t 39d488ae9f... → commit; git rev-parse 28687fe^ → 39d488ae9f9943ea5d9879bf2dd503c34370b24a (exact match).
  • Unit pytest -m "not integration": 231 passed, 1 skipped, 47 deselected — twice, unchanged.
  • Key-free integration pytest -m "integration and not llm": 28 passed — twice, unchanged.
  • mkdocs build --strict clean (exit 0, no warnings), throwaway venv from requirements-docs.txt.
Nothing was tagged, published or released.
After merge, release-please will regenerate PR #61 — the version and changelog can be verified there.
@nadeem4
ci: pin the first release to 0.1.0 and scope its changelog
f8d3137
release-please opened its first release PR proposing 1.0.0 with a changelog
containing 228 entries covering the entire history of the repository.
Two causes, two fixes:
The `refactor!:` that collapsed the distributions is a breaking change, so
release-please bumped MAJOR. `bump-minor-pre-major: true` applies semver's
pre-1.0 rule instead, so a breaking change moves 0.x to 0.(x+1) rather than
to 1.0.0. Placed top-level, where it is the default for every package.
There are no tags in the repository, so release-please had no baseline and
walked all history. `bootstrap-sha` stops the commit scan at 39d488a, the
parent of 28687fe (the first PR of this phase), so the changelog covers this
phase. It is top-level because the schema does not accept it per-package. It
is ignored once a release PR has merged and can be removed then.
The version itself is pinned by the footer below rather than by a `release-as`
config key: that key is sticky and would pin every subsequent release to
0.1.0, and the schema marks the per-package form deprecated in favour of the
commit footer. The footer expires with this commit, so there is nothing to
remember to remove.
Release-As: 0.1.0
@nadeem4
nadeem4
merged commit ea9106b
into
mainAug 28, 2026

8 checks passed

@nadeem4
nadeem4
deleted the

ci/pin-first-release-to-0-1-0

branch
August 28, 2026 14:30
@nadeem4nadeem4
mentioned this pull request
Sep 1, 2026
 Open

Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


No reviews


Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

1 participant

@nadeem4

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length > 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms");
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
ci: pin the first release to 0.1.0 and scope its changelog - #64
Merged
nadeem4 merged 1 commit into
mainfrom 
ci/pin-first-release-to-0-1-0
Aug 28, 2026
Merged
ci: pin the first release to 0.1.0 and scope its changelog#64
nadeem4 merged 1 commit into
mainfrom 
ci/pin-first-release-to-0-1-0
Conversation
@nadeem4
@nadeem4nadeem4
commented
Aug 28, 2026

Copy link


Copy Markdown

Owner
Release PR #61 (chore: release main) is not mergeable as intended. Two defects, both observed on it.
Defect 1 — it proposes 1.0.0, not 0.1.0
Task 10 landed as refactor!: collapse distribution to .... The ! marks a breaking change, so release-please bumps MAJOR. The generated changelog header reads:
## [1.0.0](https://github.com/nadeem4/nl2sql/compare/v0.1.0...v1.0.0)
### ⚠ BREAKING CHANGES
* collapse distribution to nl2sql, nl2sql-api, nl2sql-adapter-sdk

The plan calls for a 0.1.0 beta, and the maintainer has confirmed 0.1.0.
Defect 2 — the changelog is the entire repository history
It contains 228 entries — every feat: ever committed (e.g. "add AggregatorNode", "Add CLI for NL2SQL LangGraph pipeline"), including many predating this work, several duplicated.
There are zero tags in the repo (verified local and remote), so release-please has no baseline and walks all history. Note the compare URL above references a v0.1.0 tag that does not exist.
The three knobs
Each was verified against googleapis/release-pleasedocs/manifest-releaser.md, README.md and schemas/config.json before being applied.
bump-minor-pre-major: true — top-level
Schema description (definitions.ReleaserConfigOptions.properties):
Breaking changes only bump semver minor if version < 1.0.0
So while the version is below 1.0.0 a feat!/fix! moves 0.1.0 to 0.2.0, which is semver's rule for a pre-1.0 public API. Without it the next breaking commit lands on 1.0.0 by accident — which is precisely defect 1.
Valid both top-level and per-package (the root schema allOf-inherits ReleaserConfigOptions). Placed top-level, where it is the default for the single package.
bootstrap-sha — top-level (top-level only)
You can add a top level "bootstrap-sha": <full sha value> key/value entry to the config which will cause release-please to stop there for collecting changelog commits (so choose one commit earlier than the first commit you want to include).
and
  • full sha required.
  • only applicable at top-level config.
Set to 39d488ae9f9943ea5d9879bf2dd503c34370b24a. That is the parent of 28687fe (merge of PR #47, Phase 1 Task 1, chore: stop tracking runtime and build artifacts), so Task 1 itself is included and the changelog covers this phase rather than the whole project.
It is self-expiring:
Note: once a release-please generated PR has been merged, this config value will be ignored for all subsequent runs and can be removed.
bootstrap-sha is present in the root properties allowlist but absent from ReleaserConfigOptions, confirming it cannot go per-package.
Release-As: 0.1.0 — a commit footer, not a config key
This is the one that needed care. release-as in the config is sticky. From docs/manifest-releaser.md, immediately above the "release-as" example:
Note: once the release PR is merged you should either remove this or update it to a higher version. Otherwise subsequent manifest-pr runs will continue to use this version even though it was already set in the last release.
It does not pin one release — it pins every release, forever, to that version, silently. The schema also marks the per-package form deprecated:
[DEPRECATED] Override the next version of this package. Consider using a Release-As commit instead.
So no release-as key was added to release-please-config.json. The version is pinned by a commit footer instead, per README.md:
When a commit to the main branch has Release-As: x.x.x (case insensitive) in the commit body, Release Please will open a new pull request for the specified version.
The commit on this branch carries Release-As: 0.1.0 in its body. The footer applies to that one commit and expires with it, so there is nothing to remember to remove — which is the whole reason it was chosen over the config key. This repo merges PRs with merge commits, so the footer reaches main intact.
Changes
Only two files. CHANGELOG.md, every version number and .release-please-manifest.json are untouched.
release-please-config.json — two lines:
{
"$schema": "https://raw.githubusercontent.com/googleapis/release-please/main/schemas/config.json",
"release-type": "python",
"bootstrap-sha": "39d488ae9f9943ea5d9879bf2dd503c34370b24a",
"bump-minor-pre-major": true,
"separate-pull-requests": false,
"include-component-in-tag": false,
"packages": { ... }
}
docs/development/releasing.md — documents the pre-1.0 bump rule, what bootstrap-sha does and that it can be dropped once a real tag exists, and a !!! danger admonition on the sticky release-as config key explaining why this repo uses the footer instead and should not gain that key.
Verification
  • release-please-config.json parses as JSON.
  • git cat-file -t 39d488ae9f... → commit; git rev-parse 28687fe^ → 39d488ae9f9943ea5d9879bf2dd503c34370b24a (exact match).
  • Unit pytest -m "not integration": 231 passed, 1 skipped, 47 deselected — twice, unchanged.
  • Key-free integration pytest -m "integration and not llm": 28 passed — twice, unchanged.
  • mkdocs build --strict clean (exit 0, no warnings), throwaway venv from requirements-docs.txt.
Nothing was tagged, published or released.
After merge, release-please will regenerate PR #61 — the version and changelog can be verified there.
@nadeem4
ci: pin the first release to 0.1.0 and scope its changelog
f8d3137
release-please opened its first release PR proposing 1.0.0 with a changelog
containing 228 entries covering the entire history of the repository.
Two causes, two fixes:
The `refactor!:` that collapsed the distributions is a breaking change, so
release-please bumped MAJOR. `bump-minor-pre-major: true` applies semver's
pre-1.0 rule instead, so a breaking change moves 0.x to 0.(x+1) rather than
to 1.0.0. Placed top-level, where it is the default for every package.
There are no tags in the repository, so release-please had no baseline and
walked all history. `bootstrap-sha` stops the commit scan at 39d488a, the
parent of 28687fe (the first PR of this phase), so the changelog covers this
phase. It is top-level because the schema does not accept it per-package. It
is ignored once a release PR has merged and can be removed then.
The version itself is pinned by the footer below rather than by a `release-as`
config key: that key is sticky and would pin every subsequent release to
0.1.0, and the schema marks the per-package form deprecated in favour of the
commit footer. The footer expires with this commit, so there is nothing to
remember to remove.
Release-As: 0.1.0
@nadeem4
nadeem4
merged commit ea9106b
into
mainAug 28, 2026

8 checks passed

@nadeem4
nadeem4
deleted the

ci/pin-first-release-to-0-1-0

branch
August 28, 2026 14:30
@nadeem4nadeem4
mentioned this pull request
Sep 1, 2026
 Open

Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


No reviews


Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

1 participant

@nadeem4

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links");
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '

Skip to content
ci: pin the first release to 0.1.0 and scope its changelog - #64
Merged
nadeem4 merged 1 commit into
mainfrom 
ci/pin-first-release-to-0-1-0
Aug 28, 2026
Merged
ci: pin the first release to 0.1.0 and scope its changelog#64
nadeem4 merged 1 commit into
mainfrom 
ci/pin-first-release-to-0-1-0
Conversation
@nadeem4
@nadeem4nadeem4
commented
Aug 28, 2026

Copy link


Copy Markdown

Owner
Release PR #61 (chore: release main) is not mergeable as intended. Two defects, both observed on it.
Defect 1 — it proposes 1.0.0, not 0.1.0
Task 10 landed as refactor!: collapse distribution to .... The ! marks a breaking change, so release-please bumps MAJOR. The generated changelog header reads:
## [1.0.0](https://github.com/nadeem4/nl2sql/compare/v0.1.0...v1.0.0)
### ⚠ BREAKING CHANGES
* collapse distribution to nl2sql, nl2sql-api, nl2sql-adapter-sdk

The plan calls for a 0.1.0 beta, and the maintainer has confirmed 0.1.0.
Defect 2 — the changelog is the entire repository history
It contains 228 entries — every feat: ever committed (e.g. "add AggregatorNode", "Add CLI for NL2SQL LangGraph pipeline"), including many predating this work, several duplicated.
There are zero tags in the repo (verified local and remote), so release-please has no baseline and walks all history. Note the compare URL above references a v0.1.0 tag that does not exist.
The three knobs
Each was verified against googleapis/release-pleasedocs/manifest-releaser.md, README.md and schemas/config.json before being applied.
bump-minor-pre-major: true — top-level
Schema description (definitions.ReleaserConfigOptions.properties):
Breaking changes only bump semver minor if version < 1.0.0
So while the version is below 1.0.0 a feat!/fix! moves 0.1.0 to 0.2.0, which is semver's rule for a pre-1.0 public API. Without it the next breaking commit lands on 1.0.0 by accident — which is precisely defect 1.
Valid both top-level and per-package (the root schema allOf-inherits ReleaserConfigOptions). Placed top-level, where it is the default for the single package.
bootstrap-sha — top-level (top-level only)
You can add a top level "bootstrap-sha": <full sha value> key/value entry to the config which will cause release-please to stop there for collecting changelog commits (so choose one commit earlier than the first commit you want to include).
and
  • full sha required.
  • only applicable at top-level config.
Set to 39d488ae9f9943ea5d9879bf2dd503c34370b24a. That is the parent of 28687fe (merge of PR #47, Phase 1 Task 1, chore: stop tracking runtime and build artifacts), so Task 1 itself is included and the changelog covers this phase rather than the whole project.
It is self-expiring:
Note: once a release-please generated PR has been merged, this config value will be ignored for all subsequent runs and can be removed.
bootstrap-sha is present in the root properties allowlist but absent from ReleaserConfigOptions, confirming it cannot go per-package.
Release-As: 0.1.0 — a commit footer, not a config key
This is the one that needed care. release-as in the config is sticky. From docs/manifest-releaser.md, immediately above the "release-as" example:
Note: once the release PR is merged you should either remove this or update it to a higher version. Otherwise subsequent manifest-pr runs will continue to use this version even though it was already set in the last release.
It does not pin one release — it pins every release, forever, to that version, silently. The schema also marks the per-package form deprecated:
[DEPRECATED] Override the next version of this package. Consider using a Release-As commit instead.
So no release-as key was added to release-please-config.json. The version is pinned by a commit footer instead, per README.md:
When a commit to the main branch has Release-As: x.x.x (case insensitive) in the commit body, Release Please will open a new pull request for the specified version.
The commit on this branch carries Release-As: 0.1.0 in its body. The footer applies to that one commit and expires with it, so there is nothing to remember to remove — which is the whole reason it was chosen over the config key. This repo merges PRs with merge commits, so the footer reaches main intact.
Changes
Only two files. CHANGELOG.md, every version number and .release-please-manifest.json are untouched.
release-please-config.json — two lines:
{
"$schema": "https://raw.githubusercontent.com/googleapis/release-please/main/schemas/config.json",
"release-type": "python",
"bootstrap-sha": "39d488ae9f9943ea5d9879bf2dd503c34370b24a",
"bump-minor-pre-major": true,
"separate-pull-requests": false,
"include-component-in-tag": false,
"packages": { ... }
}
docs/development/releasing.md — documents the pre-1.0 bump rule, what bootstrap-sha does and that it can be dropped once a real tag exists, and a !!! danger admonition on the sticky release-as config key explaining why this repo uses the footer instead and should not gain that key.
Verification
  • release-please-config.json parses as JSON.
  • git cat-file -t 39d488ae9f... → commit; git rev-parse 28687fe^ → 39d488ae9f9943ea5d9879bf2dd503c34370b24a (exact match).
  • Unit pytest -m "not integration": 231 passed, 1 skipped, 47 deselected — twice, unchanged.
  • Key-free integration pytest -m "integration and not llm": 28 passed — twice, unchanged.
  • mkdocs build --strict clean (exit 0, no warnings), throwaway venv from requirements-docs.txt.
Nothing was tagged, published or released.
After merge, release-please will regenerate PR #61 — the version and changelog can be verified there.
@nadeem4
ci: pin the first release to 0.1.0 and scope its changelog
f8d3137
release-please opened its first release PR proposing 1.0.0 with a changelog
containing 228 entries covering the entire history of the repository.
Two causes, two fixes:
The `refactor!:` that collapsed the distributions is a breaking change, so
release-please bumped MAJOR. `bump-minor-pre-major: true` applies semver's
pre-1.0 rule instead, so a breaking change moves 0.x to 0.(x+1) rather than
to 1.0.0. Placed top-level, where it is the default for every package.
There are no tags in the repository, so release-please had no baseline and
walked all history. `bootstrap-sha` stops the commit scan at 39d488a, the
parent of 28687fe (the first PR of this phase), so the changelog covers this
phase. It is top-level because the schema does not accept it per-package. It
is ignored once a release PR has merged and can be removed then.
The version itself is pinned by the footer below rather than by a `release-as`
config key: that key is sticky and would pin every subsequent release to
0.1.0, and the schema marks the per-package form deprecated in favour of the
commit footer. The footer expires with this commit, so there is nothing to
remember to remove.
Release-As: 0.1.0
@nadeem4
nadeem4
merged commit ea9106b
into
mainAug 28, 2026

8 checks passed

@nadeem4
nadeem4
deleted the

ci/pin-first-release-to-0-1-0

branch
August 28, 2026 14:30
@nadeem4nadeem4
mentioned this pull request
Sep 1, 2026
 Open

Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


No reviews


Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

1 participant

@nadeem4

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default");
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
ci: pin the first release to 0.1.0 and scope its changelog - #64
Merged
nadeem4 merged 1 commit into
mainfrom 
ci/pin-first-release-to-0-1-0
Aug 28, 2026
Merged
ci: pin the first release to 0.1.0 and scope its changelog#64
nadeem4 merged 1 commit into
mainfrom 
ci/pin-first-release-to-0-1-0
Conversation
@nadeem4
@nadeem4nadeem4
commented
Aug 28, 2026

Copy link


Copy Markdown

Owner
Release PR #61 (chore: release main) is not mergeable as intended. Two defects, both observed on it.
Defect 1 — it proposes 1.0.0, not 0.1.0
Task 10 landed as refactor!: collapse distribution to .... The ! marks a breaking change, so release-please bumps MAJOR. The generated changelog header reads:
## [1.0.0](https://github.com/nadeem4/nl2sql/compare/v0.1.0...v1.0.0)
### ⚠ BREAKING CHANGES
* collapse distribution to nl2sql, nl2sql-api, nl2sql-adapter-sdk

The plan calls for a 0.1.0 beta, and the maintainer has confirmed 0.1.0.
Defect 2 — the changelog is the entire repository history
It contains 228 entries — every feat: ever committed (e.g. "add AggregatorNode", "Add CLI for NL2SQL LangGraph pipeline"), including many predating this work, several duplicated.
There are zero tags in the repo (verified local and remote), so release-please has no baseline and walks all history. Note the compare URL above references a v0.1.0 tag that does not exist.
The three knobs
Each was verified against googleapis/release-pleasedocs/manifest-releaser.md, README.md and schemas/config.json before being applied.
bump-minor-pre-major: true — top-level
Schema description (definitions.ReleaserConfigOptions.properties):
Breaking changes only bump semver minor if version < 1.0.0
So while the version is below 1.0.0 a feat!/fix! moves 0.1.0 to 0.2.0, which is semver's rule for a pre-1.0 public API. Without it the next breaking commit lands on 1.0.0 by accident — which is precisely defect 1.
Valid both top-level and per-package (the root schema allOf-inherits ReleaserConfigOptions). Placed top-level, where it is the default for the single package.
bootstrap-sha — top-level (top-level only)
You can add a top level "bootstrap-sha": <full sha value> key/value entry to the config which will cause release-please to stop there for collecting changelog commits (so choose one commit earlier than the first commit you want to include).
and
  • full sha required.
  • only applicable at top-level config.
Set to 39d488ae9f9943ea5d9879bf2dd503c34370b24a. That is the parent of 28687fe (merge of PR #47, Phase 1 Task 1, chore: stop tracking runtime and build artifacts), so Task 1 itself is included and the changelog covers this phase rather than the whole project.
It is self-expiring:
Note: once a release-please generated PR has been merged, this config value will be ignored for all subsequent runs and can be removed.
bootstrap-sha is present in the root properties allowlist but absent from ReleaserConfigOptions, confirming it cannot go per-package.
Release-As: 0.1.0 — a commit footer, not a config key
This is the one that needed care. release-as in the config is sticky. From docs/manifest-releaser.md, immediately above the "release-as" example:
Note: once the release PR is merged you should either remove this or update it to a higher version. Otherwise subsequent manifest-pr runs will continue to use this version even though it was already set in the last release.
It does not pin one release — it pins every release, forever, to that version, silently. The schema also marks the per-package form deprecated:
[DEPRECATED] Override the next version of this package. Consider using a Release-As commit instead.
So no release-as key was added to release-please-config.json. The version is pinned by a commit footer instead, per README.md:
When a commit to the main branch has Release-As: x.x.x (case insensitive) in the commit body, Release Please will open a new pull request for the specified version.
The commit on this branch carries Release-As: 0.1.0 in its body. The footer applies to that one commit and expires with it, so there is nothing to remember to remove — which is the whole reason it was chosen over the config key. This repo merges PRs with merge commits, so the footer reaches main intact.
Changes
Only two files. CHANGELOG.md, every version number and .release-please-manifest.json are untouched.
release-please-config.json — two lines:
{
"$schema": "https://raw.githubusercontent.com/googleapis/release-please/main/schemas/config.json",
"release-type": "python",
"bootstrap-sha": "39d488ae9f9943ea5d9879bf2dd503c34370b24a",
"bump-minor-pre-major": true,
"separate-pull-requests": false,
"include-component-in-tag": false,
"packages": { ... }
}
docs/development/releasing.md — documents the pre-1.0 bump rule, what bootstrap-sha does and that it can be dropped once a real tag exists, and a !!! danger admonition on the sticky release-as config key explaining why this repo uses the footer instead and should not gain that key.
Verification
  • release-please-config.json parses as JSON.
  • git cat-file -t 39d488ae9f... → commit; git rev-parse 28687fe^ → 39d488ae9f9943ea5d9879bf2dd503c34370b24a (exact match).
  • Unit pytest -m "not integration": 231 passed, 1 skipped, 47 deselected — twice, unchanged.
  • Key-free integration pytest -m "integration and not llm": 28 passed — twice, unchanged.
  • mkdocs build --strict clean (exit 0, no warnings), throwaway venv from requirements-docs.txt.
Nothing was tagged, published or released.
After merge, release-please will regenerate PR #61 — the version and changelog can be verified there.
@nadeem4
ci: pin the first release to 0.1.0 and scope its changelog
f8d3137
release-please opened its first release PR proposing 1.0.0 with a changelog
containing 228 entries covering the entire history of the repository.
Two causes, two fixes:
The `refactor!:` that collapsed the distributions is a breaking change, so
release-please bumped MAJOR. `bump-minor-pre-major: true` applies semver's
pre-1.0 rule instead, so a breaking change moves 0.x to 0.(x+1) rather than
to 1.0.0. Placed top-level, where it is the default for every package.
There are no tags in the repository, so release-please had no baseline and
walked all history. `bootstrap-sha` stops the commit scan at 39d488a, the
parent of 28687fe (the first PR of this phase), so the changelog covers this
phase. It is top-level because the schema does not accept it per-package. It
is ignored once a release PR has merged and can be removed then.
The version itself is pinned by the footer below rather than by a `release-as`
config key: that key is sticky and would pin every subsequent release to
0.1.0, and the schema marks the per-package form deprecated in favour of the
commit footer. The footer expires with this commit, so there is nothing to
remember to remove.
Release-As: 0.1.0
@nadeem4
nadeem4
merged commit ea9106b
into
mainAug 28, 2026

8 checks passed

@nadeem4
nadeem4
deleted the

ci/pin-first-release-to-0-1-0

branch
August 28, 2026 14:30
@nadeem4nadeem4
mentioned this pull request
Sep 1, 2026
 Open

Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


No reviews


Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

1 participant

@nadeem4

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers");
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
ci: pin the first release to 0.1.0 and scope its changelog - #64
Merged
nadeem4 merged 1 commit into
mainfrom 
ci/pin-first-release-to-0-1-0
Aug 28, 2026
Merged
ci: pin the first release to 0.1.0 and scope its changelog#64
nadeem4 merged 1 commit into
mainfrom 
ci/pin-first-release-to-0-1-0
Conversation
@nadeem4
@nadeem4nadeem4
commented
Aug 28, 2026

Copy link


Copy Markdown

Owner
Release PR #61 (chore: release main) is not mergeable as intended. Two defects, both observed on it.
Defect 1 — it proposes 1.0.0, not 0.1.0
Task 10 landed as refactor!: collapse distribution to .... The ! marks a breaking change, so release-please bumps MAJOR. The generated changelog header reads:
## [1.0.0](https://github.com/nadeem4/nl2sql/compare/v0.1.0...v1.0.0)
### ⚠ BREAKING CHANGES
* collapse distribution to nl2sql, nl2sql-api, nl2sql-adapter-sdk

The plan calls for a 0.1.0 beta, and the maintainer has confirmed 0.1.0.
Defect 2 — the changelog is the entire repository history
It contains 228 entries — every feat: ever committed (e.g. "add AggregatorNode", "Add CLI for NL2SQL LangGraph pipeline"), including many predating this work, several duplicated.
There are zero tags in the repo (verified local and remote), so release-please has no baseline and walks all history. Note the compare URL above references a v0.1.0 tag that does not exist.
The three knobs
Each was verified against googleapis/release-pleasedocs/manifest-releaser.md, README.md and schemas/config.json before being applied.
bump-minor-pre-major: true — top-level
Schema description (definitions.ReleaserConfigOptions.properties):
Breaking changes only bump semver minor if version < 1.0.0
So while the version is below 1.0.0 a feat!/fix! moves 0.1.0 to 0.2.0, which is semver's rule for a pre-1.0 public API. Without it the next breaking commit lands on 1.0.0 by accident — which is precisely defect 1.
Valid both top-level and per-package (the root schema allOf-inherits ReleaserConfigOptions). Placed top-level, where it is the default for the single package.
bootstrap-sha — top-level (top-level only)
You can add a top level "bootstrap-sha": <full sha value> key/value entry to the config which will cause release-please to stop there for collecting changelog commits (so choose one commit earlier than the first commit you want to include).
and
  • full sha required.
  • only applicable at top-level config.
Set to 39d488ae9f9943ea5d9879bf2dd503c34370b24a. That is the parent of 28687fe (merge of PR #47, Phase 1 Task 1, chore: stop tracking runtime and build artifacts), so Task 1 itself is included and the changelog covers this phase rather than the whole project.
It is self-expiring:
Note: once a release-please generated PR has been merged, this config value will be ignored for all subsequent runs and can be removed.
bootstrap-sha is present in the root properties allowlist but absent from ReleaserConfigOptions, confirming it cannot go per-package.
Release-As: 0.1.0 — a commit footer, not a config key
This is the one that needed care. release-as in the config is sticky. From docs/manifest-releaser.md, immediately above the "release-as" example:
Note: once the release PR is merged you should either remove this or update it to a higher version. Otherwise subsequent manifest-pr runs will continue to use this version even though it was already set in the last release.
It does not pin one release — it pins every release, forever, to that version, silently. The schema also marks the per-package form deprecated:
[DEPRECATED] Override the next version of this package. Consider using a Release-As commit instead.
So no release-as key was added to release-please-config.json. The version is pinned by a commit footer instead, per README.md:
When a commit to the main branch has Release-As: x.x.x (case insensitive) in the commit body, Release Please will open a new pull request for the specified version.
The commit on this branch carries Release-As: 0.1.0 in its body. The footer applies to that one commit and expires with it, so there is nothing to remember to remove — which is the whole reason it was chosen over the config key. This repo merges PRs with merge commits, so the footer reaches main intact.
Changes
Only two files. CHANGELOG.md, every version number and .release-please-manifest.json are untouched.
release-please-config.json — two lines:
{
"$schema": "https://raw.githubusercontent.com/googleapis/release-please/main/schemas/config.json",
"release-type": "python",
"bootstrap-sha": "39d488ae9f9943ea5d9879bf2dd503c34370b24a",
"bump-minor-pre-major": true,
"separate-pull-requests": false,
"include-component-in-tag": false,
"packages": { ... }
}
docs/development/releasing.md — documents the pre-1.0 bump rule, what bootstrap-sha does and that it can be dropped once a real tag exists, and a !!! danger admonition on the sticky release-as config key explaining why this repo uses the footer instead and should not gain that key.
Verification
  • release-please-config.json parses as JSON.
  • git cat-file -t 39d488ae9f... → commit; git rev-parse 28687fe^ → 39d488ae9f9943ea5d9879bf2dd503c34370b24a (exact match).
  • Unit pytest -m "not integration": 231 passed, 1 skipped, 47 deselected — twice, unchanged.
  • Key-free integration pytest -m "integration and not llm": 28 passed — twice, unchanged.
  • mkdocs build --strict clean (exit 0, no warnings), throwaway venv from requirements-docs.txt.
Nothing was tagged, published or released.
After merge, release-please will regenerate PR #61 — the version and changelog can be verified there.
@nadeem4
ci: pin the first release to 0.1.0 and scope its changelog
f8d3137
release-please opened its first release PR proposing 1.0.0 with a changelog
containing 228 entries covering the entire history of the repository.
Two causes, two fixes:
The `refactor!:` that collapsed the distributions is a breaking change, so
release-please bumped MAJOR. `bump-minor-pre-major: true` applies semver's
pre-1.0 rule instead, so a breaking change moves 0.x to 0.(x+1) rather than
to 1.0.0. Placed top-level, where it is the default for every package.
There are no tags in the repository, so release-please had no baseline and
walked all history. `bootstrap-sha` stops the commit scan at 39d488a, the
parent of 28687fe (the first PR of this phase), so the changelog covers this
phase. It is top-level because the schema does not accept it per-package. It
is ignored once a release PR has merged and can be removed then.
The version itself is pinned by the footer below rather than by a `release-as`
config key: that key is sticky and would pin every subsequent release to
0.1.0, and the schema marks the per-package form deprecated in favour of the
commit footer. The footer expires with this commit, so there is nothing to
remember to remove.
Release-As: 0.1.0
@nadeem4
nadeem4
merged commit ea9106b
into
mainAug 28, 2026

8 checks passed

@nadeem4
nadeem4
deleted the

ci/pin-first-release-to-0-1-0

branch
August 28, 2026 14:30
@nadeem4nadeem4
mentioned this pull request
Sep 1, 2026
 Open

Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


No reviews


Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

1 participant

@nadeem4

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode");
}
} catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); }
})();
})();

Skip to content
ci: pin the first release to 0.1.0 and scope its changelog - #64
Merged
nadeem4 merged 1 commit into
mainfrom 
ci/pin-first-release-to-0-1-0
Aug 28, 2026
Merged
ci: pin the first release to 0.1.0 and scope its changelog#64
nadeem4 merged 1 commit into
mainfrom 
ci/pin-first-release-to-0-1-0
Conversation
@nadeem4
@nadeem4nadeem4
commented
Aug 28, 2026

Copy link


Copy Markdown

Owner
Release PR #61 (chore: release main) is not mergeable as intended. Two defects, both observed on it.
Defect 1 — it proposes 1.0.0, not 0.1.0
Task 10 landed as refactor!: collapse distribution to .... The ! marks a breaking change, so release-please bumps MAJOR. The generated changelog header reads:
## [1.0.0](https://github.com/nadeem4/nl2sql/compare/v0.1.0...v1.0.0)
### ⚠ BREAKING CHANGES
* collapse distribution to nl2sql, nl2sql-api, nl2sql-adapter-sdk

The plan calls for a 0.1.0 beta, and the maintainer has confirmed 0.1.0.
Defect 2 — the changelog is the entire repository history
It contains 228 entries — every feat: ever committed (e.g. "add AggregatorNode", "Add CLI for NL2SQL LangGraph pipeline"), including many predating this work, several duplicated.
There are zero tags in the repo (verified local and remote), so release-please has no baseline and walks all history. Note the compare URL above references a v0.1.0 tag that does not exist.
The three knobs
Each was verified against googleapis/release-pleasedocs/manifest-releaser.md, README.md and schemas/config.json before being applied.
bump-minor-pre-major: true — top-level
Schema description (definitions.ReleaserConfigOptions.properties):
Breaking changes only bump semver minor if version < 1.0.0
So while the version is below 1.0.0 a feat!/fix! moves 0.1.0 to 0.2.0, which is semver's rule for a pre-1.0 public API. Without it the next breaking commit lands on 1.0.0 by accident — which is precisely defect 1.
Valid both top-level and per-package (the root schema allOf-inherits ReleaserConfigOptions). Placed top-level, where it is the default for the single package.
bootstrap-sha — top-level (top-level only)
You can add a top level "bootstrap-sha": <full sha value> key/value entry to the config which will cause release-please to stop there for collecting changelog commits (so choose one commit earlier than the first commit you want to include).
and
  • full sha required.
  • only applicable at top-level config.
Set to 39d488ae9f9943ea5d9879bf2dd503c34370b24a. That is the parent of 28687fe (merge of PR #47, Phase 1 Task 1, chore: stop tracking runtime and build artifacts), so Task 1 itself is included and the changelog covers this phase rather than the whole project.
It is self-expiring:
Note: once a release-please generated PR has been merged, this config value will be ignored for all subsequent runs and can be removed.
bootstrap-sha is present in the root properties allowlist but absent from ReleaserConfigOptions, confirming it cannot go per-package.
Release-As: 0.1.0 — a commit footer, not a config key
This is the one that needed care. release-as in the config is sticky. From docs/manifest-releaser.md, immediately above the "release-as" example:
Note: once the release PR is merged you should either remove this or update it to a higher version. Otherwise subsequent manifest-pr runs will continue to use this version even though it was already set in the last release.
It does not pin one release — it pins every release, forever, to that version, silently. The schema also marks the per-package form deprecated:
[DEPRECATED] Override the next version of this package. Consider using a Release-As commit instead.
So no release-as key was added to release-please-config.json. The version is pinned by a commit footer instead, per README.md:
When a commit to the main branch has Release-As: x.x.x (case insensitive) in the commit body, Release Please will open a new pull request for the specified version.
The commit on this branch carries Release-As: 0.1.0 in its body. The footer applies to that one commit and expires with it, so there is nothing to remember to remove — which is the whole reason it was chosen over the config key. This repo merges PRs with merge commits, so the footer reaches main intact.
Changes
Only two files. CHANGELOG.md, every version number and .release-please-manifest.json are untouched.
release-please-config.json — two lines:
{
"$schema": "https://raw.githubusercontent.com/googleapis/release-please/main/schemas/config.json",
"release-type": "python",
"bootstrap-sha": "39d488ae9f9943ea5d9879bf2dd503c34370b24a",
"bump-minor-pre-major": true,
"separate-pull-requests": false,
"include-component-in-tag": false,
"packages": { ... }
}
docs/development/releasing.md — documents the pre-1.0 bump rule, what bootstrap-sha does and that it can be dropped once a real tag exists, and a !!! danger admonition on the sticky release-as config key explaining why this repo uses the footer instead and should not gain that key.
Verification
  • release-please-config.json parses as JSON.
  • git cat-file -t 39d488ae9f... → commit; git rev-parse 28687fe^ → 39d488ae9f9943ea5d9879bf2dd503c34370b24a (exact match).
  • Unit pytest -m "not integration": 231 passed, 1 skipped, 47 deselected — twice, unchanged.
  • Key-free integration pytest -m "integration and not llm": 28 passed — twice, unchanged.
  • mkdocs build --strict clean (exit 0, no warnings), throwaway venv from requirements-docs.txt.
Nothing was tagged, published or released.
After merge, release-please will regenerate PR #61 — the version and changelog can be verified there.
@nadeem4
ci: pin the first release to 0.1.0 and scope its changelog
f8d3137
release-please opened its first release PR proposing 1.0.0 with a changelog
containing 228 entries covering the entire history of the repository.
Two causes, two fixes:
The `refactor!:` that collapsed the distributions is a breaking change, so
release-please bumped MAJOR. `bump-minor-pre-major: true` applies semver's
pre-1.0 rule instead, so a breaking change moves 0.x to 0.(x+1) rather than
to 1.0.0. Placed top-level, where it is the default for every package.
There are no tags in the repository, so release-please had no baseline and
walked all history. `bootstrap-sha` stops the commit scan at 39d488a, the
parent of 28687fe (the first PR of this phase), so the changelog covers this
phase. It is top-level because the schema does not accept it per-package. It
is ignored once a release PR has merged and can be removed then.
The version itself is pinned by the footer below rather than by a `release-as`
config key: that key is sticky and would pin every subsequent release to
0.1.0, and the schema marks the per-package form deprecated in favour of the
commit footer. The footer expires with this commit, so there is nothing to
remember to remove.
Release-As: 0.1.0
@nadeem4
nadeem4
merged commit ea9106b
into
mainAug 28, 2026

8 checks passed

@nadeem4
nadeem4
deleted the

ci/pin-first-release-to-0-1-0

branch
August 28, 2026 14:30
@nadeem4nadeem4
mentioned this pull request
Sep 1, 2026
 Open

Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


No reviews


Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

1 participant

@nadeem4