On 09/05/15 15:28, Stian Soiland-Reyes wrote:
So my -0 for a zip-only source release.
How do you know what downstream users will do with our source archive? As
an Apache Common product we should not place any limits on downstream and
future usage.
I addressed that with:
But the source release isn't in an OS distribution or automated builds.
It's a one-time gold copy.
so I'm confused as to what you think the source-release ('src') is for.
and why do you think automated builds are working (repeatedly) off the
source release code tree?
Repacking for a linux distro is to build once. "users" here are not
application writers (they use maven central) but people wanting a gold
copy to verify, building thier own binaries.
tar.gz is standard UNIX archive, for instance with Docker images it would
work out of the box, while zip requires apt-get install unzip (or using jar
x).
Concretely - why isn't a docker build using the maven artifacts? (this
is a library, not an application).
A scan of /dist/ shows no standard practice but one version (zip or
tar.gz) is possibly more common that multiple forms. "ant" has three forms.
Given that both are built automatically and we really only need one of the
RC reviewers to verify the file content matches the other (I can contribute
a script), then it is not a particularly large overhead IMHO.
I am more worried about the multiple confusing -source archives in the
Maven repo (probably the two Maven parents overlapping)
The Apache parent produces one ("source-release" zip).
It's the commons parent that is creating the two 'src'
We might as well do what it does.
Andy
and the lack of any
automated verification of the binaries that go straight into Maven Cental
- even though they are secondary to the source release these are what will
appear around the world.
What might we do there?
Isn't that the role of building from source release?
On 8 May 2015 16:07, "Andy Seaborne" <[email protected]> wrote:
On 08/05/15 13:45, Stian Soiland-Reyes wrote:
On 7 May 2015 at 21:29, Andy Seaborne <[email protected]> wrote:
Suggestion:
Only produce the zip version so there is exactly one "source release"
file
and so only one to check.
I think it's good to have both for longevity, and for the benefit of
OS distributions and automated builds, zip is after all a confusingly
defined format, and it is just a diff -ur to check their content is
the same.
It is a trade off - if there are two files, they both need checking or
some way to guarantee they have the same content.
But the source release isn't in an OS distribution or automated builds.
It's a one-time gold copy.
It's not like we will have a very large download page :)
(btw - could someone draft that? How is that done in Commons way? I
remember something to watch out for is chmod +x on the cgi-bin..)
What I wondered is why the proposed source distributions in
dist.apache.org are not simply byte-wise equal to the -src in
https://repository.apache.org/content/repositories/orgapachecommons-1095/org/apache/commons/commons-rdf-parent/0.1.0-incubating/
?
(and why does that folder contain bout -src and -source-release.zip?)
(Don't worry, the files inside it are byte-equal to the ones in the
proposed release archives - except that -source.zip also contains the
harmless examples/ folder)
Good question.
source-release is from the Apache parent.
