On 30 August 2018 at 15:35, Gary Gregory wrote:
> But SNAPSHOT builds _are_ publicly available on repository.apache.org. Sure
> they come and go and you cannot rely on their permanence.
Just about all our code is available from URLs that don't require logins.
However only formal releases should
Java 10 removed, among other things, the activation framework, and it's
easier to dump it than to fool around with the optional dependency, for us
and for users (if there were any). Any objections to my merging this to
master and resuming preparations for, now, a 2.0 release?
Thanks,
Matt
On Thu,
Hi.
On Thu, 30 Aug 2018 19:28:37 +0100, Stephen Colebourne wrote:
What I would love to see it a release of commons-math 3
Is it usual to release an unsupported codebase?
If yes, is there someone willing to work on this?
with an
Automatic-Module-Name for Java 9 modules (potentially the only
c
To answer my own question, we already have JaCoCo reporting configured, so
I am going to remove javancss rather than be hobbled in terms of what code
we can write.
Matt
On Thu, Aug 30, 2018, 2:43 PM Matt Benson wrote:
> It ended up being quite easy to get the unit test to pass, though the new
>
It ended up being quite easy to get the unit test to pass, though the new
functionality is no more tested than was the existing username/password
functionality.
I do find in attempting to generate the site that, despite the plugin's
having been set to build with Java 8, it seems that the javancss
What I would love to see it a release of commons-math 3 with an
Automatic-Module-Name for Java 9 modules (potentially the only
change). You could use the release as a way of advertising the
progress towards v4.
Stephen
On Thu, 30 Aug 2018 at 19:16, Gilles wrote:
>
> On Thu, 30 Aug 2018 07:35:12
On Thu, 30 Aug 2018 07:35:12 -0700, Gary Gregory wrote:
But SNAPSHOT builds _are_ publicly available on
repository.apache.org. Sure
they come and go and you cannot rely on their permanence.
And, perhaps, developers do not check what's available there...
Reports keep coming showing that they do
But SNAPSHOT builds _are_ publicly available on repository.apache.org. Sure
they come and go and you cannot rely on their permanence.
Gary
On Thu, Aug 30, 2018, 04:50 sebb wrote:
> SNAPSHOT builds must only be published to Commons developers.
> They cannot be published on public download pages.
SNAPSHOT builds must only be published to Commons developers.
They cannot be published on public download pages.
Also they may disappear or be replaced at any time.
Beta builds are subject to a release VOTE, and so can be published in
the usual way.
Once published, they are permanently available.
On 30 August 2018 at 11:19, Thomas Vandahl wrote:
> On 28.08.18 12:03, sebb wrote:
>> On 28 August 2018 at 09:25, Mark Struberg wrote:
This is unlikely to happen as long as it does not cover multi-module builds
>>>
>>> The maven-release-plugin covers multi-module releases since many years.
>
On 29.08.18 01:18, sebb wrote:
>> It doesn't check out the tag into a separate directory to build the release
>> artifacts?
>
> Last time I checked it did not.
The release:perform goal does this and always did. See target/checkout.
Bye, Thomas
---
On 28.08.18 12:03, sebb wrote:
> On 28 August 2018 at 09:25, Mark Struberg wrote:
>>> This is unlikely to happen as long as it does not cover multi-module builds
>>
>> The maven-release-plugin covers multi-module releases since many years.
>>
>> In the projects I'm working on there is no 'release
What's the difference to a nightly build being published to the Apache
Snapshot repo?
Benedikt
Am Mi., 29. Aug. 2018 um 21:51 Uhr schrieb Gary Gregory <
garydgreg...@gmail.com>:
> We do not have hard rules for betas AFAIK. IMO, only a beta can depend on
> another beta, for example see HttpCompon
13 matches
Mail list logo