[jira] [Comment Edited] (MNG-6064) Add "dev" string item into ComparableVersion

["Hui Wang (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/MNG-6064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15383026#comment-15383026 ] 

Hui Wang edited comment on MNG-6064 at 7/18/16 8:46 PM:
--------------------------------------------------------

Sorry, I remembered the wrong scenario and actually the test failed at this kind of situation: 

{code}
      1.0.1-dev.1.uncommit+5612df0 < 1.0.1
{code}

From our perspective, the order is: 
{code}
1.0.1-dev < 1.0.1-alpha < 1.0.1-beta < 1.0.1-milestone < 1.0.1-rc < 1.0.1-snapshot < 1.0.1 < 1.0.1-sp 
{code} 
So if the "dev" item was added , it would be at the first place in _QUALIFIERS.  

We're using Maven's ComparableVersion for comparing versions because it has sophisticated, flexible algorithms and was capable to support the versioning strategy we was using.  Right now we adopted a more complicated versioning strategy by using the gradle plugin, and ComparableVersion class still fulfills most of the requirement except the "dev" stage. I know "dev" is not part of Maven conventions, would the team still consider to provide more flexibility on the versioning strategy and add support for it ?  Actually, not particularly for "dev", I have a following question : in method comparableQualifier(), anything not included in the_QUALIFIERS will be transferred into the size of _QUALIFIERS, concatenated by the item itself. It seems ComparableVersion considers any unknown item is indicating newer version than all recognizable items. May I know why the strategy was designed to be like that ? 
 


was (Author: hwang_core):
Sorry, the test failed at this kind of situation: 

{code}
      1.0.1-dev.1.uncommit+5612df0 < 1.0.1
{code}

From our perspective, the order is: 
{code}
1.0.1-dev < 1.0.1-alpha < 1.0.1-beta < 1.0.1-milestone < 1.0.1-rc < 1.0.1-snapshot < 1.0.1 < 1.0.1-sp 
{code} 
So if the "dev" item was added , it would be at the first place in _QUALIFIERS.  

We're using Maven's ComparableVersion for comparing versions because it has sophisticated, flexible algorithms and was capable to support the versioning strategy we was using.  Right now we adopted a more complicated versioning strategy by using the gradle plugin, and ComparableVersion class still fulfills most of the requirement except the "dev" stage. I know "dev" is not part of Maven conventions, would the team still consider to provide more flexibility on the versioning strategy and add support for it ?  Actually, not particularly for "dev", I have a following question : in method comparableQualifier(), anything not included in the_QUALIFIERS will be transferred into the size of _QUALIFIERS, concatenated by the item itself. It seems ComparableVersion considers any unknown item is indicating newer version than all recognizable items. May I know why the strategy was designed to be like that ? 
 

> Add "dev" string item into ComparableVersion
> --------------------------------------------
>
>                 Key: MNG-6064
>                 URL: https://issues.apache.org/jira/browse/MNG-6064
>             Project: Maven
>          Issue Type: New Feature
>          Components: Artifacts and Repositories
>    Affects Versions: 3.3.9
>         Environment: Any operating Systems
>            Reporter: Hui Wang
>            Priority: Minor
>              Labels: maven
>   Original Estimate: 0.5h
>  Remaining Estimate: 0.5h
>
> We're using a popular Gradle plugin "gradle-git" ( from Andrew Oberstar ) to implement Semantic Versioning with Continuous Deployment. There's a strategy supported by gradle-git that defines a "dev" stage when we have something uncommitted on a developer branch, which is very useful. Some examples to demonstrate the "dev" scenario can be found here: https://github.com/ajoberstar/gradle-git/wiki/Release%20Plugins#how-do-i-use-the-opinion-plugin
> However, current version of  org.apache.maven.artifact.versioning.ComparableVersion does not support "dev" stage since there's no item "dev" in the field _QUALIFIERS of nested class StringItem. And since this is a private static final field, it is not able to be overwritten by inheritance. Can we add the "dev" item into _QUALIFIERS ? 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)