Addon Development and Release Methodology

Overview

This methodology was developed to ensure that project knowledge, design decisions, testing outcomes and implementation history remain available even when individual conversations, development sessions or collaborators are no longer present.

My addon development process combines human-led design, AI-assisted implementation, structured testing, controlled repository promotion and archive-based traceability.

The objective is not simply to produce working software. Every significant change should be testable, reviewable, understandable, reproducible and, where necessary, reversible.

---

1. Problem Identification

Development begins with an observation, requirement or problem.

Examples include:

  • a user-experience issue;
  • an accessibility improvement;
  • a bug report;
  • a missing feature;
  • an architectural concern;
  • platform-specific behaviour.

The problem is discussed and analysed before implementation begins. The intended outcome and completion criteria should be understood before a solution is selected.

---

2. Human–AI Collaborative Design

The desired outcome is defined through discussion.

AI assists by:

  • evaluating technical feasibility;
  • proposing implementation approaches;
  • identifying risks and limitations;
  • researching relevant APIs and documentation;
  • producing candidate solutions.

The human remains responsible for:

  • project direction;
  • domain knowledge;
  • design decisions;
  • testing strategy;
  • acceptance or rejection of proposed changes;
  • final release approval.

AI assists the engineering process but does not replace project ownership or human judgement.

---

3. Development Build Creation

A development build is produced for testing.

Every development build is considered experimental until it has been validated through User Acceptance Testing.

Each significant build should receive:

  • a version or build identifier;
  • implementation notes;
  • appropriate changelog entries;
  • defined test requirements.

Significant builds are treated as engineering evidence rather than disposable artefacts. Minor intermediate states do not need to be retained when they add no useful diagnostic, historical or rollback value.

---

4. User Acceptance Testing

Every significant change is validated through structured User Acceptance Testing (UAT).

Testing should consider:

  • expected functionality;
  • edge cases;
  • regression risks;
  • accessibility;
  • platform-specific behaviour;
  • real-world use;
  • behaviour outside the planned test path.

The objective is not merely to determine whether the code runs. Testing must establish whether the implementation addresses the original problem without causing unacceptable changes elsewhere.

A failed UAT result returns the build to development. It does not become a release.

---

5. Build Archiving

Significant development builds are archived with enough supporting information to identify and understand them.

Archived material may include:

  • development ZIPs;
  • candidate release ZIPs;
  • changelogs;
  • UAT scripts and results;
  • implementation notes;
  • release documentation;
  • Engineering Collaboration Records.

The archive provides:

  • project history;
  • rollback points;
  • testing evidence;
  • diagnostic context;
  • a record of how the implementation evolved.

Archive records and public release packages serve different purposes. An archived development build must not be mistaken for an approved release.

---

6. Success and Failure Preservation

Successful and unsuccessful development paths may both be retained when they provide useful engineering knowledge.

A failed build may document:

  • approaches that did not work;
  • platform limitations;
  • incorrect assumptions;
  • architectural dead ends;
  • abandoned implementation strategies;
  • regressions or unexpected interactions.

Failures should be retained selectively rather than indiscriminately. A failure is worth preserving when it explains a decision, prevents repetition, supports diagnosis or records a meaningful platform limitation.

---

7. Repository Promotion

Once a build has successfully completed UAT and demonstrates stable behaviour, its validated source is promoted to the project's canonical repository.

The repository should represent the approved project state and its validated development history, not an unidentified collection of experimental files.

Promotion should be supported by:

  • a successful implementation;
  • an appropriate version update;
  • changelog records;
  • UAT evidence;
  • documented design decisions where necessary;
  • confirmation that unrelated files, generated data and secrets are excluded.

Repository history must preserve licences, original attribution and the distinction between original authorship and later modifications.

---

8. Controlled Revision and Rollback

If a later version introduces a problem, development can return to an earlier validated source and consult the relevant archive records.

For example:

Version 1

  • significant development history;
  • relevant failures;
  • validated release.

Version 2

  • significant development history;
  • relevant failures;
  • validated release.

Version 3

  • current development;
  • active investigation.

If Version 3 encounters problems, development can revisit:

  • the validated Version 2 source;
  • relevant Version 2 failures and abandoned approaches;
  • associated changelogs;
  • UAT documentation;
  • recorded design rationale.

Rollback should restore a known validated state. It should not silently discard later evidence or overwrite the record of what went wrong.

---

9. Archive Lifecycle Management

Storage is finite, so archive retention is managed pragmatically.

Historical material should be retained long enough to provide:

  • rollback capability;
  • design history;
  • problem-solving context;
  • testing and engineering evidence.

Once a project reaches a stable position, redundant archive generations may be removed. Before deletion, confirm that the remaining records preserve:

  • the current validated release;
  • at least one useful rollback point where practical;
  • significant failure knowledge that remains relevant;
  • required licensing, attribution and release records;
  • any material needed for ongoing investigation.

Example:

Current

  • Version 3 validated release.

Retained

  • Version 2 validated release;
  • significant Version 2 failures.

Removed

  • redundant Version 1 intermediate builds;
  • failures whose lessons are preserved elsewhere.

The objective is to preserve useful engineering history without retaining unnecessary duplication indefinitely.

---

10. Release Packaging Standard

A release package consists of a distributable ZIP accompanied by its release and testing records.

  • Project.zip — the distributable project archive;
  • CHANGELOG.txt — the release history and implementation record;
  • UAT_SCRIPT.txt — the installation, test and acceptance procedure.

For an ESO addon, Project.zip must contain one correctly named addon folder. That folder contains:

  • ProjectManifest.txt — the addon manifest;
  • the addon's runtime files and required assets.

The addon folder must not be wrapped inside an additional duplicate directory.

The release ZIP must not contain unrelated development material, including:

  • repository metadata such as .git;
  • backups or temporary files;
  • editor or operating-system files;
  • logs or unnecessary test data;
  • credentials, private keys or secrets;
  • unrelated projects;
  • additional source ZIPs.

The archive must open and extract successfully. The addon manifest, folder name and release version must agree, and required dependencies must be declared accurately.

Original licences, copyright notices, acknowledgements and author attribution must be preserved. Later modifications must be identified separately and must not obscure the original authors.

CHANGELOG.txt

The changelog records, where applicable:

  • previous version number & UAT failures identified;
  • new version number;
  • additions;
  • fixes;
  • removals;
  • behavioural changes;
  • implementation notes;
  • known limitations.

UAT_SCRIPT.txt

The UAT script records:

  • preparation requirements;
  • installation or upgrade steps;
  • test procedures;
  • expected results;
  • regression checks;
  • completion criteria.

Release approval should be based on completed UAT results, not merely the existence of a UAT script.

---

11. Traceability and Knowledge Preservation

Every significant change should be traceable through the records appropriate to that change, which may include:

  • design discussions;
  • implementation decisions;
  • archived builds;
  • testing activities and outcomes;
  • changelog entries;
  • repository history;
  • Engineering Collaboration Records.

Not every conversation needs to be preserved in full. Important decisions, recurring standards and lessons that may affect future work should be promoted into durable project documentation.

This keeps the development process understandable across sessions, AI models, devices and time without relying solely on conversational memory.

---

12. Result

This methodology produces more than software.

It produces:

  • documented engineering history;
  • traceable decision-making;
  • structured testing evidence;
  • controlled repository states;
  • rollback capability;
  • maintainable releases;
  • long-term project knowledge;
  • demonstrable software-engineering practices.

The result is a development ecosystem in which successful releases are supported by evidence, meaningful failures contribute knowledge and projects evolve through structured continuous improvement.