commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (COMPRESS-399) OSGI package versions are overly pessimistic, except when they're overly optimisic
Date Fri, 02 Jun 2017 20:33:04 GMT

    [ https://issues.apache.org/jira/browse/COMPRESS-399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16035372#comment-16035372
] 

ASF GitHub Bot commented on COMPRESS-399:
-----------------------------------------

Github user sesuncedu commented on the issue:

    https://github.com/apache/commons-compress/pull/26
  
    It's difficult to generalize, since the packageinfo files have to be put in
    with the source code. Since a  export header parameter with an explicit
    version overrides packageinfo and annotations, defaults can be problematic.
    
    Adding the resource copy and rat excludes is good, as is keeping up with
    the felix bundle versions.
    
    Adding a bundle:baseline goal to the parent verify phase is a really,
    really good idea if bundle headers are going to be generated. Package
    versions MUST  follow semver (bundle versions also, but to a lesser
    extent).
    
    
    Maven versions theoretically ought to too, but dependencies are usually
    point versions not ranges.
    
    (Of course, there's always guava, where version is a major release, except
    for bug fixes, which are minor.)
    
    The real  work is getting the api and implementation(s) properly
    modularized so that the api isn't always affected by implementation
    changes.  At least jigsaw has gotten people to start thinking about
    modules. Not always sensibly....
    
    On Jun 2, 2017 2:38 PM, "Gary Gregory" <notifications@github.com> wrote:
    
    > Hi,
    >
    > Should any of this work also apply to commons-parent?
    >
    > Gary
    >
    > —
    > You are receiving this because you authored the thread.
    > Reply to this email directly, view it on GitHub
    > <https://github.com/apache/commons-compress/pull/26#issuecomment-305876373>,
    > or mute the thread
    > <https://github.com/notifications/unsubscribe-auth/AAZIG7Xv74lnd98TXW3kzw9huxG2US7Rks5sAFaZgaJpZM4NukX5>
    > .
    >



> OSGI package versions are overly pessimistic, except when they're overly optimisic 
> -----------------------------------------------------------------------------------
>
>                 Key: COMPRESS-399
>                 URL: https://issues.apache.org/jira/browse/COMPRESS-399
>             Project: Commons Compress
>          Issue Type: Bug
>          Components: Build
>    Affects Versions: 1.14
>            Reporter: Simon Spero
>            Priority: Minor
>             Fix For: 1.15
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> The OSGI versions in the current distributions are not being correctly generated.  OSGI
relies on package version numbers following semantic version properly for correct resolution.
 
> Current version numbers have been generated from the maven version. This has lead to
new minor version increases for packages that have no API changed; it has also concealed 
 major (breaking) changes to several packages since 1.0.
> I have created two branches that address the issue.
> Both add the bundle:baseline goal to the verify phase of the build. 
> The also both have packageinfo files added to every package, containing the package version.
These are picked up by the bundle manifest generator, and are used if no explicit version
is given in the "Export-Package" command. 
> Both branches bump the major version number for packages with any minor changes to 2.0.0.
 This makes the bundle correct, but does not fix improper import declarations made by users
of earlier bundles.   
> One branch uses the version number  from the oldest version that has no changes when
compared to HEAD, and which has not had any breaking changes since 1.0.0.  This will fail
the build because version numbers should be increasing, and may cause issues if an importing
bundle uses a range that requires an identical, but higher numbered version of the package
> The other branch uses version 1.14.0 for all packages with no major changes. 
> A third alternative, which I didn't add, is to just set all packages be version 1.14.0,
and just bump major versions when required going forward. The bulk of the major changes happened
a good few versions back,  so it's not as bad as it could be. 
> If you have a preferred option, I can create a pull request on Github 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Mime
View raw message