-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rebuilding claimed version snapshot from historic commit #78
Labels
Milestone
Comments
I've defaulted to being restrictive where I wasn't sure if the behavior should be allowed. I agree with you that this should be allowed, though I don't know if it's a simple change. My initial thoughts are that the behavior should be:
|
ajoberstar
added a commit
that referenced
this issue
May 29, 2018
This includes a partial fix for #78.
ajoberstar
added a commit
that referenced
this issue
May 30, 2018
This includes a partial fix for #78.
If you want to check out 0.7.0-rc.1 this should work now. Thanks for opening and providing a test! |
Hi, just tried 0.7.0 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently, reckon doesn't allow me to rebuild historic snapshots from old commits (with clean repo) if the subsequent normal version has already been released. Let's assume the following project setup:
Plugin settings:
Repo:
Now I want to rebuild
X
from a clean repo state, but reckon complains, saying:In my opinion it should be possible to rebuild
0.1.0-SNAPSHOT
fromX
when there are no local changes present and the0.0.1
Tag is the lowest normal version within the successor commits reachable fromX
.Of course I can still use
-Preckon.scope=major
or-Preckon.scope=patch
to build1.0.0-SNAPSHOT
or0.0.1-SNAPSHOT
in this example, if the subsequent normals have not been claimed yet.But the behavior above can be particularly painful, since I am not able to import old revisions (e.g. when im
git bisect
ing) of my project into Eclipse using buildship with the build failing.I wrote a small (failing) test, illustrating the expected behavior:
esz/reckon@dbe10e34ac53a514cb6b6b750e9209c6673c4d01
What do you think about that? Am I just overlooking some valid reason for this restrictive behavior? If you think this would be a useful addition, I'd contribute happily!
The text was updated successfully, but these errors were encountered: