commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Spero <sesunc...@gmail.com>
Subject Re: OSGI Version at Package Level : some more details about the COMPRESS-399 pull request
Date Tue, 13 Jun 2017 19:12:04 GMT
On Jun 13, 2017 1:48 PM, "Gary Gregory" <garydgregory@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 <sesuncedu@gmail.com> wrote:

> On Mon, Jun 12, 2017 at 10:53 AM, Matt Sicker <boards@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 :-)
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message