[
http://jira.codehaus.org/browse/MARTIFACT-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=169603#action_169603
]
Jason Chaffee commented on MARTIFACT-35:
----------------------------------------
I wasn't suggesting supporting N variants. I was suggesting allowing users the
ability to supply their own variant. Maven would only have to support their
own variant. Basically, I am suggesting a better design/API that allows a
company to inject their own implementation without the internal workings of
maven dependent on what the actual format is. This is simply good engineering.
Also, why close the but so quickly...since it has only been a matter of minutes
no one else will have the chance to see it, vote on it, or make their own
judgements if it is worth while.
This contributes to the feeling that the maven team isn't really listening to
the users and what they really want in a build system. This request isn't
personally coming from me, but from two different companies that have asked me
to "fix" maven's versioning system because it simply does not work for them and
they cannot change the way they do it for certain reasons.
> Allow the ability to "plugin" or "inject" different versioning implementations
> ------------------------------------------------------------------------------
>
> Key: MARTIFACT-35
> URL: http://jira.codehaus.org/browse/MARTIFACT-35
> Project: Maven Artifact
> Issue Type: Improvement
> Affects Versions: 3.0
> Reporter: Jason Chaffee
>
> Currently, maven's versioning for snapshot builds is
> ${timestamp}-${build.number}. However, it is often the case that companies
> have their own versioning requirements or conventions and there are different
> models for versioning such as OSGI, etc. For example, eclipse plugin
> versioning proposal has the following:
> the major segment indicates breakage in the API
> the minor segment indicates "externally visible" changes
> the service segment indicates bug fixes and the change of development stream
> the qualifier segment indicates a particular build
> This may result their snapshot builds take the the form of 1.2.1.v20050506 or
> 1.2.1.34 depending on they wanted to represent the qualifier segment. They
> could use the timestamp in the form "v20050506" or they could use a build
> number "34".
> Also, many times companies would like to utilize the build number in the
> final release version. For example, 1.2.1-SNAPSHOT is on build 34 when a
> release is done. Instead of making the final artifact 1.2.1, they may wish
> to make the final artifact 1.2.1.34 or 1.2.1-34.
> I think it would be ok for maven to only actually implement their default
> strategy, but I think allowing a different implementation to be injected
> based on the user's needs would be extremely valuable.
> Another option is change the way <version> works in the pom. Instead of
> entering a string, perhaps it could have child elements such as the following:
> <version>
> <major>1</major>
> <minor>2</minor>
> <service>1</service>
> <qualifer>${project.build.number}</qualifer>
> <separator>.</separator>
> </version>
> Note: qualifer may be the same notion as classifier. However, it would be
> nice to be able to specify to use a "." or a "-" or a "_" separator based on
> whatever format your company abides by.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
