Comments (7)
This will be available in revapi-maven-plugin-0.8.0
that I hope to release soon. Thanks for the idea!
from revapi.
You are right that this is not possible at the moment. As I mentioned in the answer on http://stackoverflow.com/a/41233689/1969945 revapi assumes that you compare against the last release, not last build.
Could you help me understand your usecase? What will be the next steps when your CI detects an API change since the last build?
from revapi.
Thanks again for the answer. The general idea is to be able to check if proposed PR contain API regression by testing the PR with the last built version.
We do not want to check it with the last release as some choices are made and our API evolve a lot from release to release.
The process should be something like: Release 1 with a given API. Dev on release 2, each night a new snapshot is deployed. PR 1, which broke the API: we discuss if we really want to make those changes in the API, if yes we document it and maybe we decide then if we are going to do a major or minor release. Then when the time is come to do Release 2, we check it with Release 1 and verify that only the documented changes are made in the API.
from revapi.
That is actually the workflow that Revapi intends to support 😉
The process should be something like: Release 1 with a given API. Dev on release 2, each night a new snapshot is deployed. PR 1, which broke the API: we discuss if we really want to make those changes in the API, if yes we document it and maybe we decide then if we are going to do a major or minor release. Then when the time is come to do Release 2, we check it with Release 1 and verify that only the documented changes are made in the API.
If you document your API changes using Revapi: http://revapi.org/modules/revapi-basic-features/extensions/ignore.html, you don't need to a) do the extra Release1 vs. Release2 check when you release Release2 and b) you cannot run into problems of "stealth" API changes that are "lost" on you when a new snapshot is accidentally built without first resolving the API changes.
I understand though that this workflow can be a little bit tiresome when the API changes a lot.
So to support build-to-build tracking, I need to:
- be able to check "same" versions -
x.y-SNAPHOST
vs.x.y-SNAPSHOT
- make sure that the old version is taken from a snapshot repo, not locally built
from revapi.
As a side-note - the above mentioned ignore
extension is going to get some substantial improvements in the next release due to fixing of #17.
from revapi.
Oh, and if you read through http://revapi.org/modules/revapi-maven-plugin/examples/multi-file-configuration.html you can see how to set up a single "intended API changes" file for multiple versions so that you have 1 place to look for all API changes in all releases.
from revapi.
So to support build-to-build tracking, I need to:
- be able to check "same" versions - x.y-SNAPHOST vs. x.y-SNAPSHOT
- make sure that the old version is taken from a snapshot repo, not locally built
Yes this is exactly the feature I need.
Thanks for the extra information!
from revapi.
Related Issues (20)
- Usage of @Deprecated HOT 6
- java.class.externalClassExposedInAPI thrown for an API already exposed in another module HOT 1
- Possibly false-positive java.class.externalClassExposedInAPI HOT 4
- Version format check is too restrictive HOT 4
- Be able to substitute artifacts based on some pattern to handle the XWiki legacy strategy HOT 5
- Making a public constructor protected in an abstract class should not be reported as breakage HOT 2
- Maven site for revapi fails miserably
- Revapi produces inconsistent results
- Enforcing criticality HOT 2
- Running into an endless Loop at org.jvnet.hudson HOT 3
- Infinite loop in differences HOT 2
- externalClassExposedInAPI in dependencies ? HOT 15
- "Invalid element" when upgrading to revapi-java 0.27.0 HOT 2
- Potential NullPointerException in ClasspathScanner$Scanner HOT 5
- Add Concept for String or Pattern Match
- Ability to Enforce TreeFilter Ordering HOT 1
- revapi dependency org.apache.logging.log4j:log4j-core has multiple CVE against it
- how could a enum class be excluded from java.field.enumConstantOrderChanged? HOT 4
- Fix warnings reported by Maven when using the Revapi plugin
- Class visibility reduction from `public` to `package` is reported as `java.class.removed` in latest version
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 revapi.