In terms of the changes for this release, the dockerfiles has been fixed
and I believe you've reordered the steps for finalizing a release using
gradle.
I think the problem is somewhat annoying, but has not been an issue
before. If there is some consensus regarding this, I am happy to make
AFAIK it is up to the release manager.
Vladimir
Has there been any progress/solution regarding the LF and CRLF issue?
Francis
On 30/12/2019 2:43 am, Vladimir Sitnikov wrote:
Stamitis>I was thinking that if the check says that there is no problem
then apply
would be a noop.
The current logic of 'apply' is it computes the appropriate style
Stamitis>I was thinking that if the check says that there is no problem
then apply
would be a noop.
The current logic of 'apply' is it computes the appropriate style and
overwrites the file.
Do you suggest it to skip overwriting in case the only diff is line endings?
What if there are other
I was thinking that if the check says that there is no problem then apply
would be a noop.
I have the impression that source releases are necessary and obligatory so
that the ASF is covered from a legal perspective. If I am not mistaken even
companies with closed source code are obliged to
Stamatis>I guess there are people who use Windows and they still have their
editors
Stamatis>configured to use LF endings.
LF / CRLF uses Git configuration to figure out the needed line endings.
In other words, if someone configures Git to use LF rather than "platform"
line endings,
the build
Personally, I would opt for a more permissive build.
Unexpected line endings is kind of subjective.
I guess there are people who use Windows and they still have their editors
configured to use LF endings.
Moreover, checking other opensource projects it is kind of rare to release
source code in
Stamatis> do we have another option so that the build does not fail on
Windows?
It boils down to a question: should the build fail if the source files
contain unexpected line endings?
Suppose someone uses Windows, and they create test_sql_plan.txt file with
wrong line endings (==LF).
Should the
Apart from releasing the zip archives do we have another option so that the
build on the tar.gz does not fail on Windows?
I don't remember anybody complaining about this when we were using the
maven build, so I am wondering if we had some special configuration.
On Sat, Dec 21, 2019 at 2:44 AM
The broken dockerfiles are really trivial to fix and one of the reasons
I'd like to fix them and release 1.17.0 is so that I can add 1.17.0 as a
test target for Avatica-Go before releasing Avatica-Go 5.0.0.
In addition to fixing the dockerfiles, we should:
- Agree on whether we need to release
I am less familiar with the broken docker stuff. Depending on how people
think about it: If it is not a big problem, one thing could be done is to
include it into the release notes with a section that mentions it (I have
seen such practice before).
-Rui
On Fri, Dec 20, 2019 at 8:53 AM Stamatis
First of all many thanks Francis for the release of 1.16.0. Being at the
same time RM, contributor, and beta tester of the Gradle release build was
definitely not easy :)
Also special thanks to Vladimir who spend a lot of time polishing the new
build system and helping in the resolution of the
From past experience, I think it the files should become available as
long as the repository is marked as released within nexus, so this
shouldn't be too much of a problem.
On 20/12/2019 9:18 am, Vladimir Sitnikov wrote:
AFAIK it does wait for the Nexus to release, however, I have no idea if
AFAIK it does wait for the Nexus to release, however, I have no idea if
that means the files are immediately available.
Vladimir
Thanks for confirming, Vladimir. I'll fix the dockerfiles and make
1.17.0 available for voting.
Does the release repository task wait until the repository has been
fully released before returning? If so, I think it should be quite easy
to rearrange the tasks and we can get it into this
Francis>My assumption is that they should be equivalent, but I would love
to get
Francis>some confirmation first as releasing a broken 1.17.0 would cause
more work.
For instance,
I did check the difference between the -shaded.jar (1.15.0) and .jar
(1.16.0) files on nexus yesterday and they seemed to be roughly the same
size, at least much bigger than the .jar files in (1.15.0).
My assumption is that they should be equivalent, but I would love to get
some confirmation
I haven't looked into this in detail yet, but can share details on one of
the questions:
> - Can anyone confirm if the
> avatica-standalone-server-${AVATICA_VERSION}-shaded.jar and
> avatica-standalone-server-${AVATICA_VERSION}.jar.
> jars are suppose to be equivalent?
>
The Maven built used
Upon finalizing the release for Avatica 1.16.0, I noticed that the
dockerfiles would not build on docker hub. Upon investigation, it
appears that the file names of the jars on nexus has changed slightly.
The current dockerfiles [1] references
19 matches
Mail list logo
