From commits-return-7738-archive-asf-public=cust-asf.ponee.io@nuttx.apache.org Tue Apr 21 08:23:29 2020 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with SMTP id CF49918065D for ; Tue, 21 Apr 2020 10:23:28 +0200 (CEST) Received: (qmail 84022 invoked by uid 500); 21 Apr 2020 08:23:28 -0000 Mailing-List: contact commits-help@nuttx.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@nuttx.apache.org Delivered-To: mailing list commits@nuttx.apache.org Received: (qmail 84013 invoked by uid 99); 21 Apr 2020 08:23:28 -0000 Received: from ec2-52-202-80-70.compute-1.amazonaws.com (HELO gitbox.apache.org) (52.202.80.70) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 21 Apr 2020 08:23:28 +0000 From: =?utf-8?q?GitBox?= To: commits@nuttx.apache.org Subject: =?utf-8?q?=5BGitHub=5D_=5Bincubator-nuttx=5D_xiaoxiang781216_commented_on_is?= =?utf-8?q?sue_=23757=3A_Create_release_artifacts_for_release_branches?= Message-ID: <158745740817.29173.8727749621498873030.asfpy@gitbox.apache.org> Date: Tue, 21 Apr 2020 08:23:28 -0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit References: In-Reply-To: xiaoxiang781216 commented on issue #757: URL: https://github.com/apache/incubator-nuttx/pull/757#issuecomment-617031731 > I think we are not talking about the same thing here, so let me write the problem I am trying to solve. > > We are creating release branches `releases/{major}.{minor}` When these are created I want to start generating release tarballs off of this. They need to be versioned `{major}.{minor}.{patch}`. To determine the `patch` field I do this > > 1. Look for a tag in the format `nuttx-{major}-{minor}` `nuttx-{major}-{minor}-{patch}` `nuttx-{major}-{minor}-{patch}-RC` BTW, can we drop {major}.{minor}.{patch}-RC? it's hard to handle uniformly with other tags? we can start from {major}.{minor}.0 and increase the last number one by one after we fix the critical issue reported by user. The {major}.{minor},{largest} is always the > 2. If a tag is found already with the major and minor then we use the latest patch field. > 3. If a tag is not found we assume this is the first release of the `{major}.{minor}` so we create a version string of `{major}.{minor}.0` BTW, should we always create {major}.{minor}.0 tag for the first preview release? Otherwise we may miss the release tag if no any issue is reported during the public test phase. > > Once this version string is created it can be supplied to `version.sh` or the `zipme.sh` tools. > > For users that are working off of a release tag they are likely not on the release branch so we should not try to use this logic. They are not creating a potential _new_ release. Instead we should do what we are currently doing which is look for the latest tag (probably should use git describe instead of git tag, but it does not matter that much). > Yes, this is the real difference between gitver.sh and version.sh: 1.version.sh want to get the latest tag name 2.gitver.sh want to get the latest tag name for a particular release But, it's easy to detect which case the script is running in: ``` if branch-name start with "release/[0-9].[0-9]" git describe --abbrev=0 --match "nuttx-$NUTTX_VERSION"... else git describe --abbrev=0 fi ``` > This is why I explicitly did not change the existing tool and instead wrote a helper version tool that we can use in the CI process. I can call the tool something else, but it provides the functionality that we need to generate the tarball that is required for the release process. > Yes, but it will reduce the maintain cost if the effort isn't too huge to improve the current tool for the new case. Otherwise, we have to change more place if we want to change the release schema in futrure. > This is actually probably missing some logic we want which is incrementing the patch version if the commit past an exact match of `{major}.{minor}.{patch}` this ci is the best place: we can automatically increase the release tag before zipme.sh is executed. ---------------------------------------------------------------- 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. For queries about this service, please contact Infrastructure at: users@infra.apache.org