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

Enrique Arizón Benito edited comment on MNG-7221 at 9/9/21, 12:29 PM:
----------------------------------------------------------------------

Sorry for the late reply.

[~michael-o]. Regarding "they do have the time to waste not to understand" ... 
I guess this is a very simplified view on how modern software development 
works, when developers can potentially get involved in 3 or more parallel 
projects and ten of different technology stacks. In a recent project I was part 
of, developers had to manage to "juggle" with Java, CI/CD/DevOps (shell 
scripts, k8s, jenkins, ...), Python, NodeJS, go and .Net.
 It depends all on the context (context "==" budget, resources, knowledge, 
deadlines ). Without time limitations everyone would be expected to master mvn 
and read the related documentation properly. Real world is more about a 
Too-Long-Dont-Read one 
([https://github.com/tldr-pages/tldr/tree/main/pages/common] , 
[https://github.com/tldr-pages/tldr/blob/main/pages/common/mvn.md]  ).

[~khmarbaise] Not exactly. New maven versions would just need to translate 
"FUTURE" to "SNAPSHOT" when reading the version string and continue as usual. I 
guess back-porting the change to existing mvn will not be an issue. (A minor 
version since it will not break (maven-java-libs) API compatibility ). Only 
those projects that were using a old mvn setup and were not able to update it 
would suffer when trying to parse a "*-FUTURE" version, but considering that 
SNAPSHOT is used internally at will by dev.teams, It's quite unrealistic to 
think that they will switch nomenclature without first upgrading mvn.

My two cents!

 

 

 


was (Author: earizon):
Sorry for the late reply.

[~michael-o]. Regarding "they do have the time to waste not to understand" ... 
I guess this is a very simplified view on how modern software development 
works, when developers can potentially get involved in 3 or more parallel 
projects and ten of different technology stacks. In a recent project I was part 
of, developers had to manage to "juggle" with Java, CI/CD/DevOps (shell 
scripts, k8s, jenkins, ...), Python, NodeJS, go and .Net.
 It depends all on the context (context "==" budget, resources, knowledge, 
deadlines ). Without time limitations everyone would be expected to master mvn 
and read the related documentation properly. Real world is more about a 
Too-Long-Dont-Read one 
([https://github.com/tldr-pages/tldr/tree/main/pages/common] , 
[https://github.com/tldr-pages/tldr/blob/main/pages/common/mvn.md]  ).

[~khmarbaise] Not exactly. New maven versions would just need to translate 
"FUTURE" to "SNAPSHOT" when reading the version string and continue as usual. I 
guess back-porting the change to existing mvn will not be an issue. (A minor 
version since it will doesn't break API compatibility). Only those projects 
that were using a old mvn setup and were not able to update it would suffer 
when trying to parse a "*-FUTURE" version, but considering that SNAPSHOT is 
used internally at will by dev.teams, It's quite unrealistic to think that they 
will switch nomenclature without first upgrading mvn.

My two cents!



 

 

 

> Allow "FUTURE" as an alias for "SNAPSHOT"
> -----------------------------------------
>
>                 Key: MNG-7221
>                 URL: https://issues.apache.org/jira/browse/MNG-7221
>             Project: Maven
>          Issue Type: Improvement
>          Components: Core
>    Affects Versions: 3.8.2
>            Reporter: Enrique Arizón Benito
>            Priority: Minor
>             Fix For: waiting-for-feedback, wontfix-candidate
>
>
> +underlined text+SNAPSHOT versioning is an excellent idea that solve many 
> problems, still many people do not understand them, mostly because they do 
> not have the time to read the related documentation or just get confused by 
> blogs with incorrect information.
> After working with many developers with different skills and experience I 
> have found that replacing SNAPSHOT by FUTURE offers a much more intuitive 
> idea on how to use the maven snapshots.
> IMHO, allowing for nomenclature like "v1-FUTURE" as an alias for 
> "v1-SNAPSHOT" will boost the perceived  usability of maven to many non-expert 
> developers.
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to