+1 for Approach #2
> On Oct 17, 2018, at 4:10 PM, Jonathan Hurley <[email protected]> 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.
