ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Balazs Bence Sari <bs...@hortonworks.com>
Subject Re: Ambari trunk Snapshot Versioning
Date Thu, 18 Oct 2018 19:10:27 GMT
+ 1 for #2

On 10/18/18, 19:51, "Jayush Luniya" <jluniya@hortonworks.com> wrote:

    +1 for #2. 
    
    On 10/18/18, 8:35 AM, "Sandor Molnar" <smolnar@hortonworks.com> wrote:
    
        +1 for #2
        
        On 10/18/18, 4:41 PM, "Nate Cole" <ncole@hortonworks.com> wrote:
        
            I agree that #2 is a good option.  Version parsing is used in various places,
so I think we should still use a number.  It also makes it clearer to consumers of the spi
to know where to pull in dependencies.
            
            -Nate
            
            On 10/17/18, 4:10 PM, "Jonathan Hurley" <jhurley@hortonworks.com> wrote:
            
                It looks like Ambari’s trunk pom.xml has not been updated with a proper
version in at least 4 years. It currently still lists trunk as 2.0.0.0-SNAPSHOT:
                https://github.com/apache/ambari/blob/trunk/pom.xml#L24
                
                This poses several problems as we try to make our artifacts more 3rd-party
friendly since it becomes ambiguous what other maven projects are actually depending on. I
think that we need to change our process to keep this version updated with every release of
Ambari. Other Apache projects seem to do this (I took a look at Nifi, Hive, Storm, etc) and
in each case, their trunk pom.xml was at least a minor version ahead of their most recent
release branch.
                
                I see three avenues for us here:
                
                  1.  We can make trunk the next “known” version of Ambari. This gives
us relatively fine grain control over snapshot artifact versioning, but also opens us up to
problems when surprise versions show up. For example, up until a few weeks ago, trunk would
have been 3.0.0.0-SNAPSHOT, however now that we have a 2.8 release off of trunk, we’d need
to change this to 2.8.0.0-SNAPSHOT.
                  2.  We can make trunk the next major version, so that it would currently
be 3.0.0.0-SNAPSHOT. After 3.0 is released, then it would move to 4.0.0.0-SNAPSHOT even though
we know that there are interim minor releases coming out (like 3.1, 3.2, etc)
                  3.  We can abandon numbering for trunk and use something like TRUNK-SNAPSHOT.
This also poses some ambiguity problems since you actually don’t know from which point in
time the snapshot is really from. There’s also a problem with our regex parsing of the version
if we switch away from the 4-digit scheme we have now.
                
                I’d like to get some opinions on this topic. I personally think that #2
makes the most sense.
                
            
            
        
        
    
    

Mime
View raw message