On Jun 13, 2017 1:48 PM, "Gary Gregory" <garydgreg...@gmail.com> wrote:
I think that the best way to see how this works is to provide a patch... then we can see how it goes. Gary- Can you clarify a few things: What would you like to see patches for - the commons parent / related mojo one or more commons projects, the Felix maven-bundle-plugin, or some combination thereof? The changes which I submitted as a pull-request for COMPRESS-399¹ (as amended) are on commons-compress only. https://github.com/apache/commons-compress/pull/26 The net changes: 1. Update the version of the maven-bundle-plugin used. 2. Add the bundle:baseline goal to the verify phase. 3. Add a "provided" scope maven dependency on org.osgi:org.osgi.annotation: for the @Version annotation. 4. Override the parent bundle:manifest configuration, with no version in the export-package (this would override any other source of version info). 5. Add initial package-info.java files to each non-empty package, initialized to the previously released version. 6. Change the travis.yml configuration to execute mvn verify as the build task. 7. Add bundle:baseline-report goal to the site phase. An example of additional work after a subsequent api change is https://github.com/apache/commons-compress/pull/27/commits/82405c13bd2688817108d3f2854387b3417a764d Some of these changes can be lifted to the parent; the initial setup of package-info.java @Version annotations requires some code. Simon ¹ OK, I made the changes, created the issue, then submitted the pull-request. On Mon, Jun 12, 2017 at 10:18 AM, Simon Spero <sesunc...@gmail.com> wrote: > On Mon, Jun 12, 2017 at 10:53 AM, Matt Sicker <boa...@gmail.com> wrote: > > > I'd love to have a semantic versioning plugin like that which can suggest > > what the version number is for the entire project. Elm (programming > > language) has a tool like that, and it works rather well in practice > (even > > though there are some popular libraries that are at version 5.0.0 already > > because of it). > > > The bundle:baseline goal does this (it's at the start of the report). > Having frequent major version bumps is a good thing if they are necessary > and the libraries are small (definitely better than having breaking changes > without the bump). > It's not as good as having *correct* semantic-version numbers of 1.4.0 :-) >
