+ 1 for #2
On 10/18/18, 19:51, "Jayush Luniya" <[email protected]> wrote:
+1 for #2.
On 10/18/18, 8:35 AM, "Sandor Molnar" <[email protected]> wrote:
+1 for #2
On 10/18/18, 4:41 PM, "Nate Cole" <[email protected]> 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" <[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.
