Hi gary.
The post looks good, but I think you can add more details about how we
detect bc in commons.
about plugin and other tool chains we used in such perpose, and result
analyzing.
Emmanuel Bourg 于 2020年6月15日周一 上午6:04写道：
> Le 14/06/2020 à 15:41, Gary Gregory a écrit :
> > In order to avoid
Le 14/06/2020 à 15:41, Gary Gregory a écrit :
> In order to avoid posting the same answer here and on GitHib over and over,
> I tried to explain BC here:
> https://garygregory.wordpress.com/2020/06/14/how-we-handle-binary-compatibility-at-apache-commons/
>
> Feedback is most welcome.
Excellent
On Sun, Jun 14, 2020 at 12:58 PM Rob Spoor wrote:
> On 14/06/2020 15:41, Gary Gregory wrote:
> > In order to avoid posting the same answer here and on GitHib over and
> over,
> > I tried to explain BC here:
> >
>
On 14/06/2020 15:41, Gary Gregory wrote:
In order to avoid posting the same answer here and on GitHib over and over,
I tried to explain BC here:
https://garygregory.wordpress.com/2020/06/14/how-we-handle-binary-compatibility-at-apache-commons/
Feedback is most welcome.
Gary
You mention that
Hello,
I don't think the "largest version detect" is done on the Repo. Maven central
offers all available versions in the metadata, and Maven locally resolves the
highest version (when latest is used)
Also since Maven central is supposed to be immutable a new coordinate sooner or
later is the
> Sure, go for it.
>
> I think we can use the default goal in Maven and use it from both TravisCI
> and GitHib Actions
Done in https://github.com/apache/commons-lang/pull/555
Similar ways can be used on any project who use commons-parent as parent.
Gary Gregory 于2020年6月14日周日 下午10:14写道：
> Sure,
Hi Matt,
thanks for the help. With your hint I could refactor a lot of the old
code. There are two questions left:
I used the PolyhedronSet to determine the intersections with a line.
First I got a Plane and then I had to find the intersection with the Plane.
My code makes use of both, the
I suppose you can ask Sonatype to offer a sort by release date feature on
that kid of query result.
Gary
On Sun, Jun 14, 2020, 10:44 Melloware Inc wrote:
> Gary,
>
> Maven Central Search does not. Se ethos URL:
> https://search.maven.org/search?q=g:commons-io
>
> Commons-IO 20030203.000550 is
Gary,
Maven Central Search does not. Se ethos URL:
https://search.maven.org/search?q=g:commons-io
Commons-IO 20030203.000550 is shown as the latest version incorrectly.
Mello
On Sun, Jun 14, 2020 at 10:29 AM Gary Gregory
wrote:
> I'm not sure what you are using, but Maven Central sorts by
I'm not sure what you are using, but Maven Central sorts by release date:
https://search.maven.org/artifact/commons-io/commons-io
Gary
On Sun, Jun 14, 2020 at 9:56 AM Xeno Amess wrote:
> It is strange to have an older version have a larger major version number
> than a newer version.
> Of
Sure, go for it.
I think we can use the default goal in Maven and use it from both TravisCI
and GitHib Actions.
Gary
On Sun, Jun 14, 2020, 09:52 Xeno Amess wrote:
> why not add a bc detect in travis-ci scripts?
>
> Gary Gregory 于2020年6月14日周日 下午9:42写道：
>
> > In order to avoid posting the same
It is strange to have an older version have a larger major version number
than a newer version.
Of course we might never witness a major version whose number be 1000+
in our life, but...
That just feels strange.
Gary Gregory 于2020年6月14日周日 下午9:52写道：
> On Sun, Jun 14, 2020 at 9:51 AM Xeno
why not add a bc detect in travis-ci scripts?
Gary Gregory 于2020年6月14日周日 下午9:42写道：
> In order to avoid posting the same answer here and on GitHib over and over,
> I tried to explain BC here:
>
> https://garygregory.wordpress.com/2020/06/14/how-we-handle-binary-compatibility-at-apache-commons/
>
On Sun, Jun 14, 2020 at 9:51 AM Xeno Amess wrote:
> Or if we should create commons-io2 and commons-BeanUtils2 like what
> we've done in lang3, as @John Patrick suggested?
>
Why?
Gary
>
> Gary Gregory 于2020年6月14日周日 下午9:39写道：
>
> > On Sun, Jun 14, 2020 at 6:40 AM Xeno Amess wrote:
> >
> >
Or if we should create commons-io2 and commons-BeanUtils2 like what
we've done in lang3, as @John Patrick suggested?
Gary Gregory 于2020年6月14日周日 下午9:39写道：
> On Sun, Jun 14, 2020 at 6:40 AM Xeno Amess wrote:
>
> > every time my update tool chain thinks 20030203.000550 is a greater
> version
>
In order to avoid posting the same answer here and on GitHib over and over,
I tried to explain BC here:
https://garygregory.wordpress.com/2020/06/14/how-we-handle-binary-compatibility-at-apache-commons/
Feedback is most welcome.
Gary
On Sun, Jun 14, 2020 at 6:40 AM Xeno Amess wrote:
> every time my update tool chain thinks 20030203.000550 is a greater version
> than 2.7 (actually it is, if see it in number).
> So have we some way to delete it from maven central? (or rename it?)
>
Yes, but we will never do that. That would
"update toolchain" here means idea's package plugin, which seems have no
way to set up rules like rules in versions-maven-plugin.
[image: image.png]
Of course we can try to only use versions-maven-plugin.
But a setting like that just hides problem, it does not solve the problem.
The real problem
On 14/06/2020 12:40, Xeno Amess wrote:
every time my update tool chain thinks 20030203.000550 is a greater version
than 2.7 (actually it is, if see it in number).
So have we some way to delete it from maven central? (or rename it?)
The same problem happened in BeanUtils, version 20030211.134440
I keep thinking that too, and ended up just using a custom versions
rule to ignore it.
Other idea maybe change to GAV to;
1) org.apache.commons:commons-io
2) org.apache.commons:commons-io2
So starting to match the commons-lang3 approach.
I find commons-lang3 is a really good pattern and is much
every time my update tool chain thinks 20030203.000550 is a greater version
than 2.7 (actually it is, if see it in number).
So have we some way to delete it from maven central? (or rename it?)
The same problem happened in BeanUtils, version 20030211.134440
21 matches
Mail list logo
