[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [orbit-dev] switch from com.spotify.docker.client to org.mandas.docker.client
|
On Fri, Jan 17, 2020 at 12:44 PM Homer, Tony <tony.homer@xxxxxxxxx> wrote:
>
> > Yes, because we're now replacing it with an "updated" version. Those wishing to continue using the older bundle, which depends on a vulnerable libraries could technically just use an older release build.
>
> Would this apply to dependencies which are being updated as well? I think we discussed this at EclipseCon and IIRC, you said that we should only keep the newest minor version (in some cases we may keep several major versions e.g., Junit 4 and 5). For one example, Orbit currently provides org.slf4j.api 1.7.2 and 1.7.10. I propose that we add 1.7.29. Would we remove both 1.7.2 and 1.7.10? In other words, would the general guide be to remove all of the old minor versions when we add an update to a newer minor version?
It's always ideal to have just 1 version, so if possible, yes the older slf4j
versions should be removed. I mean if the versioning (1.7.10 -> 1.7.29)
actually means that all changes have been not been API breaking then
absolutely.
On the other hand, as an example, you could have very large projects
that are able to maintain multiple major versions so having more than
one version should be ok.
Looking just at the orbit-recipes repo, Batik, Lucene, and BouncyCastle
make up the majority of bundles that have multiple versions so there
aren't too many cases of this.
On Fri, Jan 17, 2020 at 12:44 PM Homer, Tony <tony.homer@xxxxxxxxx> wrote:
>
> > Yes, because we're now replacing it with an "updated" version. Those wishing to continue using the older bundle, which depends on a vulnerable libraries could technically just use an older release build.
>
> Would this apply to dependencies which are being updated as well? I think we discussed this at EclipseCon and IIRC, you said that we should only keep the newest minor version (in some cases we may keep several major versions e.g., Junit 4 and 5). For one example, Orbit currently provides org.slf4j.api 1.7.2 and 1.7.10. I propose that we add 1.7.29. Would we remove both 1.7.2 and 1.7.10? In other words, would the general guide be to remove all of the old minor versions when we add an update to a newer minor version?
>
> On 1/17/20 , 9:29 AM, "Homer, Tony" <tony.homer@xxxxxxxxx> wrote:
>
> Thanks for the feedback and guidance, Roland and Matthias!
>
> I was planning on using ebr to generate the first draft of the recipes and then use a diff tool to compare with the old version with an eye to merging the old osgi.bnd into the new, so thanks for confirming that is the way to go, Roland!
>
> I will send a message to cross-project-issues with a brief summary of the background and the proposed change including the list of dependency changes, then get started on the change requests.
>
> Tony
>
> On 1/17/20 , 8:28 AM, "orbit-dev-bounces@xxxxxxxxxxx on behalf of Roland Grunberg" <orbit-dev-bounces@xxxxxxxxxxx on behalf of rgrunber@xxxxxxxxxx> wrote:
>
> On Thu, Jan 16, 2020 at 5:41 PM Homer, Tony <tony.homer@xxxxxxxxx> wrote:
> > Should I open 22 change requests (1 + 13 + 8), one giant change request for all of these changes or somewhere in between?
>
> As Matthias mentioned, they would need to be filed separately. The good
> news is that only a license check would be required, and since many of
> the packages are just updates, it should go through quickly.
>
> It would be nice to have a list of which packages are being updated, and
> which will be new. (eg. foo 1.0.0 -> 1.1.0). I'm guessing Jackson and
> Jersey packages will be the majority of the updates and probably JNR
> as well ?
>
> > Should the obsolete Spotify Docker Client and/or it’s dependencies be removed from Orbit?
> > What other communications are needed (e.g., cross-project-issues-dev)?
>
> Yes, because we're now replacing it with an "updated" version. Those
> wishing to continue using the older bundle, which depends on a vulnerable
> libraries could technically just use an older release build.
>
> I say "updated" because we're basically updating "com.spotify.docker.client" to
> "org.mandas.docker.client" yet the versions are completely different. Not only
> is the Bundle-SymbolicName changing, but all the package names as well.
> This would definitely need to be communicated. Does "org.mandas.docker.client"
> maintain the same package structure as docker-client ? Projects would need
> to be aware of how to migrate. I think it would be worth it to post to
> cross-projecct-issues with the list of dependencies you plan to update. I would
> also make it clear that the dependencies being removed can still be accessed
> by using an older release build.
>
> > Any other comments or guidance on this set of changes?
>
> I would make sure to use the "osgi.bnd" of the original bundles that are being
> updated, and hopefully the main things changing in there are version numbers.
> I would also CC Jeff Johnston from Linux Tools Project on this so that he can
> test out a draft build of the changes against the Docker tooling within that
> project.
>
> Cheers,
> Roland Grunberg
>
> _______________________________________________
> orbit-dev mailing list
> orbit-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/orbit-dev
>
>
>
> _______________________________________________
> orbit-dev mailing list
> orbit-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/orbit-dev
