I think it's time to step back a little. This whole vote was started
without any proper initial discussion, so to the extent there will be
any majority for a policy change, this will not be the vote where this
happens. But these votes tend to be great kickstarters for good
discussions, so instead of getting all focused on voting
technicalities I'd simply like to point out the following:
A) There is a clear majority to not burn version numbers in maven central.
B) The relationship between an SCM tag and a maven central version number
is really a weak link. The artifact "foobar" versioned "2.2" in
maven central could very well
point to the scm tag foobar-2.2-take-29. The pom in central could
actually have
this tag etched in. So in this case we did 28 previous SCM tags
that all contained the
same maven version number.
C) In essence, we do not really care about what the SCM tag is, as
long as there is a well established convention for tagging. If one
desires a "proper" foobar-2.2 tag this can always be made once the
final artifact is approved (although for immutability reasons, the pom
in central would point at take-29).
D) We have a clear need to identify versions for the *process* of
releasing, which means
vote threads need clear markings of "take17", which may also
correspond to a "take17" tag. But the release target is still "2.2".
(Or, as in the case of maven core, a widely available alpha release
for general consumption for the brave). These tags are used to
organize our *process*.
So I basically think this is the wrong vote we're having. Hence my -1
on this procedural issue.
Kristian
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
