A refinement of this initial proposal for using semver.org is the
following build artifact version example. It includes as informational
metadata the date of the build and the short git commit hash. This full
version is used for issue reporting and possibly other developer purposes.
9.0.0-beta.1.vote.2+20180115.d23e386
9.0.0-beta.1.vote.3+20180209.41da26b
The "user" would be presented with the following user-friendly version
(for the last voted build artifact):
9.0.0 Beta 1
The distributors of the release would use the following version
specifier (for the last voted build artifact):
9.0.0-beta.1
Best regards,
Ognyan
На 30.05.2018 в 17:48, Ognyan Kulev написа:
Hello,
I propose using -vote1, -vote2, ... suffixes. This way the reason behind
the released build becomes explicit.
Why not just use Semantic Versioning 2.0.0 <https://semver.org/>? The
semantics of all version components would be clearly defined by a
standard. The user-visible change would be using three-numbers version
9.0.0 (instead of the often used two-numbers version 9.0) that sometimes
may be presented as one-number version 9. The pre-release versions that
we are talking about would look like this:
9.0.0-rc1.vote1
9.0.0-rc2.vote1
9.0.0-rc2.vote2
9.0.0-rc2
The semver.org example for version precedence is:
1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta <
1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0
Please look at point 11 in the specification for details.
And there is build metadata syntax that may be used. It's not used in
version comparison, e.g.
9.0.0-beta1.vote3+20180202
Best regards,
Ognyan
На 30.05.2018 в 13:34, Sven Reimers написа:
+1 for build1 build2 suffixes
Sven
Geertjan Wielenga <geertjan.wiele...@googlemail.com> schrieb am Mi., 30.
Mai 2018, 12:15:
Sure, build1, etc, is also fine and ptobably clearer than vc1 etc.
Gj
On Wednesday, May 30, 2018, Jan Lahoda <lah...@gmail.com> wrote:
On Wed, May 30, 2018 at 8:59 AM, Christian Lenz
<christian.l...@gmx.net>
wrote:
What does vc mean? Vote candidate? I know the „Problem“ behind the
vote,
but if we make fixes or whatever, we have a new build, with a new
build
number so the vote was for rc1-20180303 or the build number
rc1-143. If
the
vote fails, we make some stuff like fixes or whatever and we have a
new
build so rc1-20180304 or rc1-144 or whatever. So you are still
counting
numbers but rc is confusing and vc yeah could be but it is not my
personal
favorite. It is not concrete enough. IMHO.
One thing to note is that we have released "Apache NetBeans 9.0
RC1". The
second -rc1, or -vc1, or anything else is just a marker for various
builds
and should only be seen by the developer community (and
general@incubator
),
the end users should not see that.
I don't mind the -vc1, -vc2, -vc3. An alternative might be "-build1",
"-build2" or "-b1", "-b2", etc. That would be close to what
Christian is
proposing, and might also be closer to what non-Apache folks expect.
Jan
PS: I'd like to thank Emilian for doing the RC1 release: greatly
appreciated!
Cheers
Chris
Von: Geertjan Wielenga
Gesendet: Mittwoch, 30. Mai 2018 08:55
An: dev@netbeans.incubator.apache.org
Betreff: Re: Where we are and where we are going with Apache NetBeans
9.0
But please understand what this is about — when we go through the
voting
process in Apache, the vote may fail, which has happened several times
and
then we need to make fixes, produce a new release, and start the
voting
process again.
The question is how to distinguish between these vote candidates, I
propose
vc1, vc2, vc3, etc.
What do you think?
Gj
On Wednesday, May 30, 2018, Christian Lenz <christian.l...@gmx.net>
wrote:
Rc1-rc1 doesn’t make sense at all and is confusing. It still was
confusing
for People for beta-rc1. There is no beta-rc in the wild. Either we
have
a
beta or RC but beta-rc? Wy we don’t use the build number for this or
build
date? When you download the nightly, there is a Long number in the
titlebar, I think it was the date like NetBeans 9.0-dev-20180101 or
smth
like that. So why not using beta-20180303 and for RC too? So everyone
knows, that this rc is the latest build or is 3 days old.
My 2 cents
Cheers
Chris
Von: Wade Chandler
Gesendet: Mittwoch, 30. Mai 2018 01:41
An: dev@netbeans.incubator.apache.org
Betreff: Re: Where we are and where we are going with Apache NetBeans
9.0
I don’t like the rc1-rc1 bit. I think once one knows the reason it
exists,
they can understand it, but a release candidate for a release
candidate,
is
just hard to say with a straight face IMO. I prefer the rc1-vc1 bit
myself.
Either way, I think folks will ask what it means, but at least the
words
for the shorthand match exactly what it is; voting candidate for a
release
candidate versus RC for an RC. My couple pennies.
Wade
On May 29, 2018, at 4:15 PM, Antonio <anto...@vieiro.net> wrote:
0
I don't see a problem with the "rc1-rc1", "rc1-rc2" approach.
Cheers,
Antonio
On 29/05/18 22:03, Geertjan Wielenga wrote:
We’re going to continue to use the release90 branch.
The next — and hopefully last — release candidate before the final
release
of NB 9.0 will be rc2.
We will need to vote on that release in the Apache PPMC and IPMC
just
like
all other releases.
There may be a need to vote multiple times, though we’re getting
better
at
putting releases together and so, just like for the rc1, we may
only
need
one round of votes.
Anyway, I propose we use the shortened names rc2-vc1, rc2-vc2,
rc2-vc3,
i.e., ‘vc’ standing for ‘voting candidate’, these would be for an
assumed
three rounds of Apache voting for the rc2 release, though we’ll
probably
only need rc2-vc1.
That is also the structure suggested by our mentor Bertrand.
The rc2 will be the releae on which the NetCAT and beyond
Community
Acceptance survey will be done.
Unless there are objections, I propose we use this structure. If
you
object, you should provide a counter proposal.
---------------------------------------------------------------------
To unsubscribe, e-mail:
dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail:
dev-h...@netbeans.incubator.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
