edgent-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dale LaBossiere <dml.apa...@gmail.com>
Subject Re: Understanding the snapshot and release process
Date Tue, 13 Jun 2017 13:59:32 GMT

> On Jun 12, 2017, at 5:04 PM, Christofer Dutz <christofer.dutz@c-ware.de> wrote:
> ...
> I guess also executing the pre-built test with java7 should also be possible, but I’m
struggling with one other of your requirements:
> “Only deploy everything if the java8, java7 and android builds succeed”. I hope you
can see the dilemma.
It’s possible my terminology is confusing/inaccurate.  Mostly I think I meant that for releases
(not talking about snapshots nor release-candidate staging for voting) we should only make
the final release artifacts, including convenience binaries, public only if/once all configurations
have passed testing&voting.

I think it’s time for me to go back to all the ASF release doc info.  I know a lot has changed
and earlier I didn’t pay any attention to snapshots nor maven related things because we
weren’t doing them.

> Here it might be a better option to add a Jenkinsfile to the repository and setup a Jenkins
job on the ASF Jenkins. With this I am a lot more flexible than with Travis. We could continue
to use Travis for the auto-testing of pull requests, but would live with running the java7
testsuite with a java8 VM, but have the Jenkins job deploy the SNAPSHOTS to the ASF repo.
> 
> What do you think about that? Building on Apache Machines also gives a lot of other benefits.
I don’t know why Travis was chosen.  Is the ASF Jenkins service relatively new or not good/viable
for PR-auto-test use?  Regardless, partially or fully switching to Jenkins tooling as appropriate
is OK with me - unless there are some things you forgot to mention :-)

— Dale
Mime
View raw message