nuttx-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GitBox <...@apache.org>
Subject [GitHub] [incubator-nuttx] xiaoxiang781216 edited a comment on issue #757: Create release artifacts for release branches
Date Tue, 21 Apr 2020 08:29:11 GMT

xiaoxiang781216 edited a comment 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 best release
for {major}.{minor}.
   
   > 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



Mime
View raw message