Comments (7)
it will not support that
there are many duplicates in the issue tracker
from gitlint.
I don't think there's a good fix here. Tags shouldn't be deleted. That commit could be on multiple branches and iirc tags reference the commit, not the branch so "moving" it isn't an option. I don't think pre commit is wrong either because no two ecosystems use the same versioning schemes. This isn't ideal but I don't think there's a fix here
from gitlint.
Interesting, pre-commit assumes that tags point to stable versions.
(edit: well, it doesn't, the docs clearly state it just points to the latest tag. But as pointed out, users might interpret this incorrectly as pointing to the latest stable version)
I think it’s pretty common for packages to tag pre-release versions. For example, black does this (also available in pre-commit).
In gitlint’s case, this is a recent addition with our adoption of hatch and hatch-vcs in particular, we need this for our dev builds to have versions strings like 0.19.0dev+<sha>
@asottile Perhaps pre-commit autoupdate
could support a new flag --stable
(or whatever the best name is), so it skips any tags with dev, alpha, beta, rc, a, b
in it?
from gitlint.
@asottile thanks for responding. I should've done due diligence and searched. Mea culpa.
For reference:
https://github.com/pre-commit/pre-commit/issues?q=is%3Aissue+autoupdate+pre-release+is%3Aclosed
Specific issue with a bit more detail:
pre-commit/pre-commit#995
from gitlint.
I would argue that hatch needs to be more flexible here if it isn't already. Honestly non-release tags are a lot of noise, there should be a better way to indicate the next potential version string as a dev string. I'm not familiar with hatch though so, I don't know any options off the top of my head and am on my phone at the moment
from gitlint.
So hatch-vcs uses setuptools_scm under the hood.
The Default versioning scheme section in the setuptools_scm
README explains how versions are determined.
The part that’s relevant here:
The next version is calculated by adding
1
to the last numeric component of the tag.…
Semantic Versioning (SemVer)
Due to the default behavior it's necessary to always include a patch version (the
3
in1.2.3
), or else the automatic guessing will increment the wrong part of the SemVer (e.g. tag2.0
results in2.1.devX
instead of2.0.1.devX
). So please make sure to tag accordingly.
Since gitlint versioning scheme has a patch release number (i.e. 0.18.0), setuptools_scm
by default will bump the following untagged commits after 0.18.0
as 0.18.1devN+g123abc
.
This didn’t feel right to me, hence why I added a 0.19.0dev
tag, in which case setuptools_scm
will recognize the dev
suffix and build versions like 0.19.0.devN+g123bc
.
I also didn’t entirely like having to pollute the tag list with dev
tags, but I decided in the end the trade-off was worth it.
Related side-note: I am actually thinking to do a pre-release for 0.19.0 (and hence add a tag like 0.19.0b1
or 0.19.0rc1
) very soon, next week most likely. I want to do a pre-release to be able to test release automation before actually releasing. All the puzzle pieces should be in place for this, I just need to add a trigger to publish to pypi when a new github release is created.
from gitlint.
So I noticed that our recent dev builds were being tagged with with 0.19.2devN+g123abc
instead of the desired 0.20.0devN+g123abc
. I discovered this is because the 0.19.1
tag was added more recently than the 0.20.0dev
tag. The way hatch-vcs was configured it didn’t actually parse the semver to determine the latest tag, but just looked at the last added tag to determine the next version.
I was able to fix this by switching the version scheme to release-branch-semver
in #478. Now the dev numbers are correctly increased.
A nice side-effect is that we no longer need the dev
tags - so I removed them. This probably breaks the git source builds for 0.19.dev versions, but I think that’s an ok trade-off to keep the tag list clean. The release builds will still work fine as those tags remain.
I did still keep the rc tags for 0.19.0 release as well: v0.19.0rc1
and v0.19.0rc2
. I think that’s reasonable but understand that keeping those doesn’t solve fully solve this particular issue then. If an rc tag is the latest tag on the repo, it will still be used by pre-commit when auto-updating.
At least an rc should be better than a dev build 🤷♂️
from gitlint.
Related Issues (20)
- Ability to have user-defined rules disabled by default HOT 2
- gitlint raises an exception if run without --staged and with an ignore-by-author-name configuration HOT 3
- Support for per-user configuration files and configuration inheritance HOT 9
- Ignore stdin by default in CI HOT 7
- Feature request: generate a junit or sarif report HOT 4
- Allow several --extra-path HOT 1
- gitlint and gitlint-core v0.19.0 fail to build from sdist HOT 13
- 0.20.0 Release Plan
- Enable support for git archive installs HOT 7
- Consider adopting pypi-publish GHA instead of hatch publish
- Adopt GHA environments HOT 1
- Refactor GHA pipelines for improved security HOT 4
- Investigate smoke testing of sdist package for downstream packaging HOT 3
- Commit message with a hash sign at the start is not detected HOT 5
- Full workflow example for fixing a previously rejected commit message HOT 2
- installing hook on pre-commit fails with newest virtualenv (>20.24.5) present HOT 15
- Forever violations even after being edited HOT 2
- Poetry version solving failure
- Failed to install the `pre-commit` hook HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from gitlint.