potiuk opened a new issue, #292: URL: https://github.com/apache/tooling-trusted-releases/issues/292
I attempted to annonce 0.1.0 version of Airflow-CTL from 0.1.0rc1 and it's not clear what we should put as version - is it 0.1.0 or 0.1.0rc1 https://release-test.apache.org/projects/airflow-ctl an example here: https://release-test.apache.org/compose/airflow-ctl/0.1.0 Should the version of the project be 0.1.0 or 0.1.0rc1 - and how are we going to do 0.1.0rc2 ? Some more details: When we release our distributions, we always prepare x.y.z from x.y.zrcN (rc1, rc2, etc.) They way how we do it - is that in SVN we add versions (both packages and sourcs) that have 0.1.0 - no matter if they are 0.1.0rc1 or 0.1.0rc2) - they always have 0.1.0 - because we are assuming that at the moment we get 3 +1 vote, those exact same binary identical packaages are going to be promoted to 0.1.0. In PyPI - we upload different packages: https://pypi.org/project/apache-airflow-ctl/0.1.0rc1/ Those .whl and .sdist packages have 0.1.0rc1 as version - (our release process has separate step to prepare those packages to be uploaded to PyPI) - because packages in PyPI are immutable - so once we upload 0.1.0 we can replace them Now = this means the packages we are voting on (in SVN) have 0.1.0 version (they are in SVN in 0.1.0rc1 folder) : https://dist.apache.org/repos/dist/dev/airflow/airflow-ctl/0.1.0rc1/ If - in the future - we cancel the vote and replace the candidate with 0.1.0rc2, this will still be - technically voting on 0.1.0 but FROM 0.1.0rc2 (the files will have the same 0.1.0 name - but they will be put in 0.1.0rc2 folder). This makes me thinkk about the following questions: Q1: Should we use 0.1.0 as a version number of the release candidate or rc1 (I assume the answer is yes - 0.1.0) - because we cannot have rc1 and rc2 ... voting at the same time, 0.1.0 seems to be appropriate "umbrella" for all RC* candidates. Depending on the answer to that questions - the below questions Q2/Q3 might be not relevant - if the idea is that each "version" is RC - I assume there is no need of separately tagging the revisions, as they will contain RC1/RC2 already in the version name. Q2: If the answer above is "yes" Is there a way we can name revisions of the same version to be RC1/RC2 and so on ? I have not seen that option - but that might be handy if we can name those revisions with suffixes to indicate RC* version we have now - say "name latest revision" option. Q3: Following up after Q3 -> is there a possibility of **replacing** past uploads with the new one (I saaw Upload files - but not "replace files" - I assume that if we upload same named files, they will be replaced, so that would work but possibly this could be explicitly stated or explained in the contest of Q2 (maybe when uploading we could add a suffix?) ? Depending on answer to Q1 - this will be likely a different answer, but it is applicable in either case: Q4: Is there a way to refer to "base version" or "rc versions" in the templates for emails? I saw I'd like to call a vote on releasing the following artifacts as `Apache [PROJECT] [VERSION]` - but our templates are more similar to: ``` [VOTE] Release Airflow CTL ${VERSION} from ${VERSION_RC} ``` https://github.com/apache/airflow/blob/main/dev/README_RELEASE_AIRFLOWCTL.md#prepare-voting-email-for-airflow-ctl-release-candidate So we need a way - in a single mail template to refer to both - base (final) version and currently voted RC version. Can we do it and how? Q5: In case the answer to Q1 is "use 0.1.0rc1" - are we going to somehow "promote" the RCN that passes the vote to be the final version? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
