[jira] [Work logged] (COMPRESS-399) OSGI package versions are overly pessimistic, except when they're overly optimisic
[
https://issues.apache.org/jira/browse/COMPRESS-399?focusedWorklogId=705768=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-705768
]
ASF GitHub Bot logged work on COMPRESS-399:
---
Author: ASF GitHub Bot
Created on: 08/Jan/22 23:02
Start Date: 08/Jan/22 23:02
Worklog Time Spent: 10m
Work Description: HelderMagalhaes commented on a change in pull request
#26:
URL: https://github.com/apache/commons-compress/pull/26#discussion_r780715492
##
File path:
src/main/java/org/apache/commons/compress/archivers/ar/package-info.java
##
@@ -0,0 +1,23 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+@Version("1.14.0")
Review comment:
**Git attributes** seems to be the way in a git-only world. Performing
[Keyword
Expansion](https://git-scm.com/book/en/v2/Customizing-Git-Git-Attributes) to
create a `$Version$` keyword or similar.
In the meantime, an Interesting bit from an [SO
thread](https://stackoverflow.com/a/11535358):
> You have to be careful, though, because the .gitattributes file is
committed and passed around with the project, but the driver (in this case,
dater) isn’t, so it won’t work everywhere. When you design these filters, they
should be able to fail gracefully and have the project still work properly.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 705768)
Time Spent: 40m (was: 0.5h)
> 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
> Original Estimate: 0h
> Time Spent: 40m
> 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] [Work logged] (COMPRESS-399) OSGI package versions are overly pessimistic, except when they're overly optimisic
[
https://issues.apache.org/jira/browse/COMPRESS-399?focusedWorklogId=701200=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-701200
]
ASF GitHub Bot logged work on COMPRESS-399:
---
Author: ASF GitHub Bot
Created on: 26/Dec/21 16:22
Start Date: 26/Dec/21 16:22
Worklog Time Spent: 10m
Work Description: garydgregory commented on a change in pull request #26:
URL: https://github.com/apache/commons-compress/pull/26#discussion_r775261084
##
File path:
src/main/java/org/apache/commons/compress/archivers/ar/package-info.java
##
@@ -0,0 +1,23 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+@Version("1.14.0")
Review comment:
I don't think we want to touch all these files for every release. Isn't
there a different way to do this?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 701200)
Time Spent: 0.5h (was: 20m)
> 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
> Original Estimate: 0h
> Time Spent: 0.5h
> 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
(v8.20.1#820001)
[jira] [Work logged] (COMPRESS-399) OSGI package versions are overly pessimistic, except when they're overly optimisic
[ https://issues.apache.org/jira/browse/COMPRESS-399?focusedWorklogId=610459=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-610459 ] ASF GitHub Bot logged work on COMPRESS-399: --- Author: ASF GitHub Bot Created on: 14/Jun/21 07:53 Start Date: 14/Jun/21 07:53 Worklog Time Spent: 10m Work Description: garydgregory commented on pull request #26: URL: https://github.com/apache/commons-compress/pull/26#issuecomment-860048832 Please rebase on master. Recent changes should allow all builds to be green including Java 16 and 17-EA. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 610459) Time Spent: 20m (was: 10m) > 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 > Original Estimate: 0h > Time Spent: 20m > 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 (v8.3.4#803005)
[jira] [Work logged] (COMPRESS-399) OSGI package versions are overly pessimistic, except when they're overly optimisic
[ https://issues.apache.org/jira/browse/COMPRESS-399?focusedWorklogId=610360=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-610360 ] ASF GitHub Bot logged work on COMPRESS-399: --- Author: ASF GitHub Bot Created on: 14/Jun/21 07:43 Start Date: 14/Jun/21 07:43 Worklog Time Spent: 10m Work Description: HelderMagalhaes commented on pull request #26: URL: https://github.com/apache/commons-compress/pull/26#issuecomment-859735226 (typo in the title -- optimisic -> optimistic -- which may be good to fix before it's part of some release notes generation. ) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 610360) Time Spent: 10m > 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 > Original Estimate: 0h > Time Spent: 10m > 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 (v8.3.4#803005)
