You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue tracks the discussion around handling major/minor version bump automatically.
Should we have a workflow that is triggered on a git tag push event, that bumps this line to the next version? Since we do not have version branches, this wouldn't be that trivial to implement. What do we do if the current version in main is, for example, 1.11.1, but we want to create a tag for 1.20?
Should we bump the version based on Conventional Commits? E.g we add [bugfix] as prefix to the commit, and this automatically bump the minor version. How do we automatically handle multiple features/commit in a single release?
We do not provide support for other cloud providers apart from AWS, yet the version file is in the shared package. I would not worry about it right now, as no support for other cloud providers is in the horizon, but I'd keep in mind while choosing the best approach. Related to this, the current tag name pattern does not match what it is written in version.py (i.e lambda-vX.X.X instead of vX.X.X)
One possible approach is to trigger a github action to "release" (i.e creating git tag and possibly deploy on SAR) whenever version.py is modified.
The content you are editing has changed. Please copy your edits and refresh the page.
my preference would be to track the version number using git tags as the primary source. we can create a version.py file at deploy time (via the script), which can be used at runtime to populate the version number. if we try to deploy a version that already exists, the deploy script should fail - how can we track this part? is there a way to query the existing version in SAR?
we also have to remove the manual tracking of the version number in the changelog file. one way to do this would be to utillize something like the elastic-agent-changelog-tool, but we could just as easily roll some simple automation triggered off new git tags, which does something like this and then commits the new file before writing the tag.
This issue tracks the discussion around handling major/minor version bump automatically.
Should we have a workflow that is triggered on a git tag push event, that bumps this line to the next version? Since we do not have version branches, this wouldn't be that trivial to implement. What do we do if the current version in main is, for example, 1.11.1, but we want to create a tag for 1.20?
Should we bump the version based on Conventional Commits? E.g we add [bugfix] as prefix to the commit, and this automatically bump the minor version. How do we automatically handle multiple features/commit in a single release?
We do not provide support for other cloud providers apart from AWS, yet the version file is in the shared package. I would not worry about it right now, as no support for other cloud providers is in the horizon, but I'd keep in mind while choosing the best approach. Related to this, the current tag name pattern does not match what it is written in version.py (i.e
lambda-vX.X.X
instead ofvX.X.X
)One possible approach is to trigger a github action to "release" (i.e creating git tag and possibly deploy on SAR) whenever
version.py
is modified.Related tasks
The text was updated successfully, but these errors were encountered: