The main thing to keep in mind is that the whole team is aware of the
status during voting and afterwards (email history).
The RC approach that others have mentioned works well with that in mind.
Apache Groovy doesn't use that approach but the vote email conventions that
we use and tagging keep
You might find this helpful [1], section "10. Roll Out"
[1] https://cwiki.apache.org/confluence/display/BIGTOP/How+to+release
--
With regards,
Cos
On 2020-06-02 22:08, Nikita Ivanov wrote:
Gents - for my education, could you please explain how this would work (or
typically works in other
+1 - sorry, missed that line!
--
With regards,
Cos
On 2020-06-02 14:31, Furkan KAMACI wrote:
Hi Konstantin,
Actually, that's what I've suggested:
https://lists.apache.org/thread.html/rcb20fe26dbeba39c75861cee7f48a30f472b807079f2a1ebcbd1a7a3%40%3Cdev.nlpcraft.apache.org%3E
Kind Regards,
Gents - for my education, could you please explain how this would work (or
typically works in other projects)?
1. Do we release, say, 1.0.0-rc1 on PPMC, then, when voted, rename all
artefacts to 1.0.0 and submit to IPMC?
2. Release 1.0.0-rc1, then, when voted, cut another release from the same
Hi Konstantin,
Actually, that's what I've suggested:
https://lists.apache.org/thread.html/rcb20fe26dbeba39c75861cee7f48a30f472b807079f2a1ebcbd1a7a3%40%3Cdev.nlpcraft.apache.org%3E
Kind Regards,
Furkan KAMACI
On Tue, Jun 2, 2020 at 9:24 AM Konstantin Boudnik wrote:
> Guys,
>
> perhaps it
Guys,
perhaps it would makes sense to start marking release candidates (RCs) to vote
on as it makes it easier to distinguish them apart. Having a few RCs aren't
that unusual as issues could be found during the review/vote process. However,
voting repeatedly on what seems like the same version
