Comments (6)
I've seen this and haven't spent enough time to pinpoint.
However, I believe it has to do with branches. Possibly the tag was created on a now non-existent branch?
from miniver.
@kmpf This is probably because you are querying for the version from a commit that does not have the later tags (v1.1
, v2.0.0
etc.) as ancestors.
If you link to the repo in question and what commit you're pointing at then we can debug further.
here's the logic that determines the latest version.
We first try
git describe --long --always --first-parent
then, if that errored out, we try
git describe --long --always
The man
page for git describe
says the following about the --first-parent
flag:
--first-parent
Follow only the first parent commit upon seeing a merge commit. This is useful when you wish to not match tags on branches merged in the history of the target commit.
So as @chinghwayu says this is probably related to having tags that are on different branches.
from miniver.
Hi, sorry for the late reply. I work on a non-public version, but I tested it with the master of https://github.com/fraunhofer-izi/uap
I think the behaviour has to do with the difference in annotated and unannotated tags. After cloning the above mentioned repo I did:
$ git describe --long --always --first-parent
a7980c51
$ git describe --long --always
v1.0.3-1413-ga7980c51
$ git describe --long --always --tags
v2.0.0rc2-76-ga7980c51
I don't know which kind if behaviour you want miniver to have. You could provide an option to use unannotated tags, maybe?
from miniver.
Just realized there already is a patch to add the --tags
switch. The documentation did not trigger my attention, because I did not see the error mentioned there.
from miniver.
I don't know which kind if behaviour you want miniver to have. You could provide an option to use unannotated tags, maybe?
Just realized there already is a patch to add the
--tags
switch. The documentation did not trigger my attention, because I did not see the error mentioned there.
Ah, yes... ran into this as well.
What if git describe
was executed twice, with and without --tags
? If results are different, print a warning.
If a switch such as -u
is used, execute only once with --tags
.
from miniver.
I wanted to use miniver
for my project, but then I just hit the issue of forced usage of --first-parent
. I don't think it's a good idea to deviate from the git defaults and hardcode in a different approach, with no option to change it. Consider this very common scenario:
●─╮ [develop] Merge branch 'master' into develop
│ ∙ [master] <1.1> publish a hotfix
∙ │ do some development
◎─╯ <1.0> initial commit
In this case, git describe
outputs 1.1-2-g445f312
, which is correct, because my codebase is based on version 1.1. However,
git describe --first-parent
(which is what miniver
does by default) outputs 1.0-2-g445f312
, which is incorrect and misleading. When I see my program (running on current develop
) claiming that it's 1.0+something, it seems like the hotfix is not included. This also brings inconsistency between the program (using miniver
) and e.g. tarball name/prefix generated through git describe
).
I feel like the default approach should be changed, or at least an option to set this should be offered (perhaps as an argument to miniver install
, if possible), ideally both.
from miniver.
Related Issues (20)
- make `install-miniver` offer to tag `v0.1.0-dev` if it detects no tags when installing
- make miniver work with other package layouts
- move CI to GitHub Actions HOT 1
- Clarify relation to setuptools HOT 2
- How does this work when doing `pip install .`? HOT 2
- Installation does not work with 'src' package layout HOT 4
- Make `ver` command work without explicitly providing a package name
- Make running `miniver` with no arguments run `miniver ver` HOT 3
- Add tests and documentation for `version` command
- miniver refuses to use git's version if the package is not at the repository's root
- Allow distributions that place packages in an arbitrary directory
- Call _static_version and _version from miniver package directory
- Python versions
- `# -*- coding: utf-8 -*-`
- Re-definition of builtin `exit`
- Consistent handling of dev releases HOT 1
- git fails if not owned by user
- Support setup.cfg HOT 2
- [BUG] miniver does not detect "dirty" state when all changes are staged
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 miniver.