Ticket #603 (closed Task: worksforme)
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:2 Changed 11 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.
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