[Psy-Fer]

Release plan

Version	Theme	Done when
v0.1.0	First release	Released 2026-05-04.
v0.2.0	STAR parity build	Default output matches STAR 2.7.11b on the validation sets in CONTRIBUTING.md. Every known difference is listed in DIVERGENCE.md. Non-STAR additions sit behind their own flag or cargo feature and are off by default. Every open PR has been dealt with.
v0.3.0	Wider testing and fixes	Parity checked through nf-core pipelines (Nextflow) on a range of datasets, species and library types. Whatever that turns up is fixed. A few more extras, still behind flags or features.
v0.4.0	Performance	A dedicated pass over the whole pipeline for speed and memory, beyond the performance work already in v0.2.0, with output unchanged: every performance change is checked against the same differential as a parity change.
v0.5.0	Parity release	The release we publish as a STAR 2.7.11b parity aligner.
after v0.5.0	Normal development	rustar-aligner extends and diverges from STAR through regular development cycles with scverse and contributors.

Until v0.5.0 the rule is: port STAR as written, and anything that isn't STAR is opt-in.

Code under a sensitive licence needs discussion before any work starts

rustar-aligner is MIT-licensed and published. Code that is ported from, adapted from, or written
while reading another project's source carries that project's licence with it. A permissive
licence (MIT, BSD, Apache 2.0) is fine with a notice in LICENSES/. Anything else is a
sensitive licence, and a contribution that touches one will most likely not be accepted
unless the way it was developed has been discussed and agreed with the maintainers first. This
is a legal question, not a code-quality one, so a good implementation does not change the answer.

A licence is sensitive if it:

• restricts use or redistribution: proprietary, "internal use only", source-available,
  non-commercial, or tied to a vendor's product;
• is copyleft (GPL, LGPL, AGPL, MPL and similar), whose terms would reach our MIT code;
• is missing: code with no licence is all rights reserved.

If your work reproduces the behaviour of a tool under a sensitive licence:

1. Open an issue before writing code. Say which tool, which behaviour, and how you intend to
   develop it (for example from public documentation, published papers, or observed inputs and
   outputs). A maintainer will apply the sensitive license label and the discussion
   happens there.
2. Do not read, port, or paraphrase the source. That includes having an AI assistant read it
   for you. A rewrite done by someone (or something) that has read the source is not a clean
   room, and deleting a ported module and rewriting it in the same branch does not remove the
   derivation. Git history keeps the ported commits even after a squash.
3. State the provenance in the PR: what each part was developed from, and confirm that no
   source under a sensitive licence was consulted.

PRs found to contain code derived from source under a sensitive licence are labelled
sensitive license and are not merged while the question is open. If the derivation is
confirmed, the PR is closed. Its history cannot be cleaned up after the fact.