Ticket #603 (closed Task: worksforme)

Opened 5 years ago

Last modified 4 years ago

Naming Scheme for DM4 Plugins and Version Numbers

Reported by: JuergeN Owned by: jri
Priority: Major Milestone:
Component: DeepaMehta Standard Distribution Version: 4.1.3
Keywords: Cc: mre, dgf
Complexity: 3 Area:
Module:

Description

When I look at the plugins at http://ci.deepamehta.de I get totaly lost as I do not know which version of the plugin referes to which version of DeepaMehta. Therefore I would very much appreciate a naming convention here. Also I think that the names of the plugins are often not chosen very well, as they do hardly tell much about the plugin's true purpose.

Here is my suggestion for a naming convention:

A B C

dm4x-put_your_good_name_here-0.0.0.jar

A: The version of DeepaMehta that the plugin referes to.
B: A "good" name for the plugin - telling something useful about the plugin's purpose.
C: The version of the plugin.

From what understood in our last discussion about DM4 version numbers, we should only need the first two numbers of DeepaMehta releases here, as the third one is for bugfixing only that would not influence the compatibility with existing plugin version.

In that sense, an example for an existing plugin with DeepaMehta release 4.2.x would be:

OLD NAME: deepamehta-webactivator-0.4.x.jar
NEW NAME: dm42-advanced-webactivator-0.4.x.jar

The description text in the download list should be mandatory!

For the nightly SNAPSHOT that means, that after the Release of DeepaMehta 4.2 the next SNAPSHOT would be 4.3-SNAPSHOT. A bug fix in 4.2 would be 4.2.1.

So for the plugin that would refer to 4.3-SPAPSHOT it would be

NEW NAME: dm43-SNAPSHOT-advanced-webactivator-0.4.y.jar

What do you think about this?

Change History

comment:1 Changed 5 years ago by jri

On a recent meeting (Jan 20, 2014) JuergeN, Malte, and jri decided the following. Basically it's what JuergeN proposed in the ticket description.

RULE

  • Starting from now DM makes use of Semantic Versioning (however, not in the "original" style as described on semver.org):
    • MAJOR number (4) stays until the next DM rewrite
    • MINOR number changes when DM breaks the API or introduces new API
    • PATCH number changes for bug fixes or new minor features (without API changes)
  • Every plugin .jar file has a dm4x- prefix, x being the minor number of the DM release the plugin is compatible with.

Example:

dm42-cool-plugin-0.5.jar
  • A plugin snapshot release that is compatible with a DM snapshot has SNAPSHOT twice in its name:
    dm43-SNAPSHOT-cool-plugin-0.8-SNAPSHOT.jar
    
Last edited 5 years ago by jri (previous) (diff)

comment:2 Changed 5 years ago by jri

Until now we focused only on forward compatibility, that is "does my plugin run on a future DM version?", but not on backward compatibility, that is "does my plugin run in an older DM installlation?". In order to let the plugin prefix, e.g. "dm42-" tell the user about backwards compatibility as well the rule (comment:1) must be extended: also the introduction of new (non-breaking) API must increase the MINOR number, just as with breaking API. So, the prefix actually reflects the API version. The rule is updated accordingly.

comment:3 Changed 5 years ago by jri

  • Milestone Release 4.2 deleted

comment:4 Changed 4 years ago by jri

  • Status changed from new to closed
  • Resolution set to worksforme

The plugin naming scheme is meanwhile established

Note: See TracTickets for help on using tickets.