Added directory for docs, and added our version schema for future use

CHANGELOG.md

@@ -1,9 +1,9 @@
-# v2.6.1.0
-- Replace Trimmomatic with Atria
-
 # v2.6.0.0
 - Updated verison to reflect the new versioning scheme, which is described in `docs/version_schema.md`.
 
+# v2.5.4
+- Fixed fatal bug in `configs/run_validation.config` that prevents users from running the `RUN_VALIDATION` workflow.
+
 # v2.5.3
 - Added new LOAD_SAMPLESHEET subworkflow to centralize samplesheet processing
 - Updated tags to prevent inappropriate S3 auto-cleanup

configs/run_validation.config

@@ -24,5 +24,4 @@ includeConfig "${projectDir}/configs/containers.config"
 includeConfig "${projectDir}/configs/resources.config"
 includeConfig "${projectDir}/configs/profiles.config"
 includeConfig "${projectDir}/configs/output.config"
-includeConfig "${projectDir}/configs/read_type.config"
 process.queue = "will-batch-queue" // AWS Batch job queue

docs/version_schema.md

@@ -0,0 +1,15 @@
+# Version naming scheme for mgs-workflow
+
+From version 2.6.0.0 we're adopting a new 4-number versioning scheme, described below. The primary purpose of this system is to communicate clearly to users of the pipeline what changes they must make when interpreting or using the outputs of the pipeline in downstream applications
+
+1. **Major:** The first number in the version will be incremented each time we seriously rework the pipeline, requiring potentially major changes to downstream code.
+2. **Schema:** The second number will be incremented each time we restructure or rename pipeline outputs, requiring downstream code to be changed to correctly access output files.
+3. **Results:** The third number will be incremented each time the results are no longer directly comparable to previous versions.
+4. **Point:** The fourth number will be incremented any other time the pipeline code changes in a manner that doesn't meet the criteria above, such as changes that impact performance but not results; changes to documentation; options that are off by default; and new outputs that don't interfere with existing outputs.
+
+Users relying on pipeline outputs should take the following actions in response to pipeline changes:
+
+1. **Point change or higher:** Review changes for new outputs and options that could be relevant to user's application.
+2. **Results change or higher:** Review changes for effects on output interpretation; show caution in comparing outputs across the version boundary.
+3. **Schema change or higher:** Update downstream code to reflect new output schema.
+4. **Major change:** Review new code and outputs thoroughly; be prepared for major changes to downstream code.