Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 8D132200C88 for ; Fri, 2 Jun 2017 09:48:08 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 8B4A3160BDD; Fri, 2 Jun 2017 07:48:08 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id D0D32160BD1 for ; Fri, 2 Jun 2017 09:48:07 +0200 (CEST) Received: (qmail 83956 invoked by uid 500); 2 Jun 2017 07:48:07 -0000 Mailing-List: contact issues-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: issues@commons.apache.org Delivered-To: mailing list issues@commons.apache.org Received: (qmail 83945 invoked by uid 99); 2 Jun 2017 07:48:06 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 Jun 2017 07:48:06 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id 7A8AF1A026D for ; Fri, 2 Jun 2017 07:48:06 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -99.202 X-Spam-Level: X-Spam-Status: No, score=-99.202 tagged_above=-999 required=6.31 tests=[KAM_ASCII_DIVIDERS=0.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id 8nrdNFhuBEf0 for ; Fri, 2 Jun 2017 07:48:05 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTP id E5E185FE37 for ; Fri, 2 Jun 2017 07:48:04 +0000 (UTC) Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id 62F5FE00A0 for ; Fri, 2 Jun 2017 07:48:04 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id 1CA6C21B58 for ; Fri, 2 Jun 2017 07:48:04 +0000 (UTC) Date: Fri, 2 Jun 2017 07:48:04 +0000 (UTC) From: "Stefan Bodewig (JIRA)" To: issues@commons.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (COMPRESS-399) OSGI package versions are overly pessimistic, except when they're overly optimisic MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Fri, 02 Jun 2017 07:48:08 -0000 [ https://issues.apache.org/jira/browse/COMPRESS-399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16034292#comment-16034292 ] Stefan Bodewig commented on COMPRESS-399: ----------------------------------------- I must admit that OSGi has been a low priority for us, likely neither of the people working on Compress uses OSGi. Personally I'd go with your third option. Is there some sort of tooling that would tell us we are changing a package in an incompatible way so we'd know when to bump anything? We do run japicmp http://commons.apache.org/proper/commons-compress/japicmp.html but I'm not sure it is reliable enough. At first I was afraid using new major versions would cause trouble when/if we ever wanted to create a Compress 2.0, but then again we would change the base package to be org.apache.commons.compress2 for this release. > 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)