Separate Field for Versions in Project Settings

[kaveritekawade]

Resolves #518

Feature Description:

This PR introduces a new "Version" field in the Project settings to allow users to specify the desired version for their projects.

Changes Made:

• Added a new field labeled "Version" under Project settings.
• Implemented the functionality to input the desired version number.

Expected Behavior:

• Users can now input the desired version number directly within the Project settings.
• The version information will be stored and displayed accordingly.

Additional Information:

This enhancement aims to improve the user experience by providing a clear and organized way to manage project versions. It will facilitate better tracking of changes and ensure compatibility between different versions of projects.

[oliverfoster]

How should the version number be incremented?

[kaveritekawade]

How should the version number be incremented?

The "major.minor.patch" scheme can be applied to reflect the significance and nature of the changes made to the course.

Major Version (X.0.0):

Significant Changes: Increment for major updates affecting course structure, content, or functionality.
Examples: Redesigning layout, introducing core features, major content overhauls.

Minor Version (X.Y.0):

New Features & Enhancements: Increment for new features or improvements without altering the course structure.
Examples: Adding interactive elements, integrating new media, content improvements.

Patch Version (X.Y.Z):

Bug Fixes & Minor Updates: Increment for bug fixes or minor corrections.
Examples: Layout fixes, typo corrections, usability adjustments.

[oliverfoster]

How should the version number be incremented?

The "major.minor.patch" scheme can be applied to reflect the significance and nature of the changes made to the course......

I struggle to see content editors understanding semver rules and manually applying them constantly - some property changes are "breaking", such as enabling or disabling spoor. The increment pattern would be open to lots of varying interpretation I'd imagine, and therefore not be very useful through time.

What is the use-case for a human reading the version number? When would it be read, who by and what information are they getting from it?

I recognise that it is useful to have a value which differentiates course changes.

It would be nice if we could automate version number bumps according to fixed rules, and possibly add release notes as well.

Could we instead, have a single number, say _builds = 0 and increment it every time the course is built? I feel like that would more precisely and automatically capture the essential information about the distance between two courses but without the confusing rules.

[kaveritekawade]

How should the version number be incremented?

The "major.minor.patch" scheme can be applied to reflect the significance and nature of the changes made to the course......

I struggle to see content editors understanding semver rules and manually applying them constantly - some property changes are "breaking", such as enabling or disabling spoor. The increment pattern would be open to lots of varying interpretation I'd imagine, and therefore not be very useful through time.

What is the use-case for a human reading the version number? When would it be read, who by and what information are they getting from it?

I recognise that it is useful to have a value which differentiates course changes.

It would be nice if we could automate version number bumps according to fixed rules, and possibly add release notes as well.

Could we instead, have a single number, say _builds = 0 and increment it every time the course is built? I feel like that would more precisely and automatically capture the essential information about the distance between two courses but without the confusing rules.

The version number is crucial for hosting a course on an LMS. Our custom plugin uploads the course, generating version-specific links to differentiate between course releases and assist in tracking performance and usage analytics.

Currently, the version number field in our custom plugins causes mismatches when maintaining version numbers across different plugins. To ensure consistency, we'd like this field to be available at the course level rather than the plugin level.

We rely on input from content creators to input the version number according to their requirements. We shouldn't automatically update the build number since it's a configurable field.

[oliverfoster]

You can extend the course object with an extension schema, it would have the same effect as adding the entry to the core schema.

Such as in plp schema.

Example:

{
  "type": "object",
  "$schema": "http://json-schema.org/draft-04/schema",
  "id": "http://jsonschema.net",
  "required": false,
  "globals": {
  },
  "properties": {
    "pluginLocations": {
      "type": "object",
      "required": true,
      "properties": {
        "config": {
          "type": "object"
        },
        "course": {
          "type": "object",
          "properties": {
            "_version": {
              "type": "string",
              "required": true,
              "default": "1.0.0",
              "inputType": "Text",
              "validators": [
              "required"
              ],
              "help": "This will be added to the course's manifest file metadata. It is not (currently) displayed anywhere within the course."
            }
          }
        },
        "contentobject": {
          "type": "object"
        },
        "article": {
          "type": "object"
        },
        "block": {
          "type": "object"
        },
        "component": {
          "type": "object"
        }
      }
    }
  }
}

Have you tried this?

Currently, the version number field in our custom plugins causes mismatches when maintaining version numbers across different plugins. To ensure consistency, we'd like this field to be available at the course level rather than the plugin level.

Could you elaborate on the issue please?