I have set up a chain of build jobs in Jenkins.
The root of the chain is
https://builds.apache.org/job/maven-3.2-release-status/
This builds at midnight UTC every monday.
If there are changes to the master branch of Maven since the last release
of Maven then that build will pass and kick off
On 13 February 2014 15:14, Stephen Connolly stephen.alan.conno...@gmail.com
wrote:
We have not made a release of Maven 2.x since 2.2.1 which was August 2009.
During that period no release manager has stepped up to cut a release.
I would argue that we should just therefore just declare Maven
Sorry, but I don't think this is a good way to do releases. Honestly I think
it's a potential recipe for disaster.
As I said before, it's the lack of work being done in the core that is the
issue. Releases aren't being made because until recently there isn't a lot of
activity in the core. Just
Am 2014-02-18 16:26, schrieb Stephen Connolly:
I have set up a chain of build jobs in Jenkins.
The root of the chain is
https://builds.apache.org/job/maven-3.2-release-status/
The certificate has expired today, hopefully infra will fix this ASAP.
Michael
Well all this will be for the moment is a reminder that the best tests we
have say it is releasable and that a *human* can think about cutting a
release.
Right now it will fail to notify because there are failing integration
tests (need a 3.2.1 in central to fix the three failing tests)
If we
On Feb 18, 2014, at 11:47 AM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
Well all this will be for the moment is a reminder that the best tests we
have say it is releasable and that a *human* can think about cutting a
release.
Right now it will fail to notify because there
GitHub user everflux opened a pull request:
https://github.com/apache/maven-indexer/pull/3
Update to lucene 4.6 with new API
Please note that the version is changed for local development. You may want
to bump it to 6.0.0 to communicate the API break clearly.
You can merge this
On Tuesday, 18 February 2014, Jason van Zyl ja...@takari.io wrote:
On Feb 18, 2014, at 11:47 AM, Stephen Connolly
stephen.alan.conno...@gmail.com javascript:; wrote:
Well all this will be for the moment is a reminder that the best tests we
have say it is releasable and that a *human* can
On Feb 18, 2014, at 2:19 PM, Stephen Connolly stephen.alan.conno...@gmail.com
wrote:
On Tuesday, 18 February 2014, Jason van Zyl ja...@takari.io wrote:
On Feb 18, 2014, at 11:47 AM, Stephen Connolly
stephen.alan.conno...@gmail.com javascript:; wrote:
Well all this will be for the
Perhaps a stupid question, however if no change goes in, and it kicks off
and gives the same gold star as the previous week, then there's no point to
releasing it, because it's the same thing, what takes care of this? Just
the human going well, actually there were no commits, so this email is
On 18 February 2014 22:47, Jason van Zyl ja...@takari.io wrote:
On Feb 18, 2014, at 2:19 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
On Tuesday, 18 February 2014, Jason van Zyl ja...@takari.io wrote:
On Feb 18, 2014, at 11:47 AM, Stephen Connolly
On Feb 18, 2014, at 3:20 PM, Stephen Connolly stephen.alan.conno...@gmail.com
wrote:
Well for one that is not how RM works or has worked here.
Really? When I have planned to release core it takes some effort that requires
more effort than the normal components. So if it's not clear from
On 18 February 2014 23:58, Jason van Zyl ja...@takari.io wrote:
On Feb 18, 2014, at 3:20 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
Well for one that is not how RM works or has worked here.
Really? When I have planned to release core it takes some effort that
requires
Looking for common ground here, how about we start by documenting the core
release procedure so that someone else could plausibly take a turn? Without
knowing the details of the release process, I don't see how I could disagree
with JvZ.
It mostly seems to me that Stephen's desired schedule
Looking for common ground here, how about we start by documenting the core
release procedure so that someone else could plausibly take a turn? Without
knowing the details of the release process, I don't see how I could disagree
with JvZ.
It mostly seems to me that Stephen's desired schedule
On Feb 18, 2014, at 4:32 PM, Benson Margulies bimargul...@gmail.com wrote:
Looking for common ground here, how about we start by documenting the core
release procedure so that someone else could plausibly take a turn? Without
knowing the details of the release process, I don't see how I
On Feb 18, 2014, at 4:23 PM, Stephen Connolly stephen.alan.conno...@gmail.com
wrote:
If they are releases that we intend users picking up, then there needs to
be a vote.
That's not true. Official releases need to be voted on, if people pick the
product of a nightly or wander into the
There's an Apache nuance to highlight here.
We may not advertise non-voted items to the general public. We may
offer non-voted items to engaged community members.
I do not know enough about Eclipse to offer an intelligent comparison.
Eclipse development process distinguishes several build types [1], so I
am wondering if you really want to do weekly full releases or your
goal is to have something closer to integration builds in eclipse
nomenclature.
I see two major downsides doing weekly full releases.
First, one week just
GitHub user Tibor17 opened a pull request:
https://github.com/apache/maven-surefire/pull/33
fixed tests for SUREFIRE[1055]
The parallel tests should check the test count so that all have completed
successfully.
This is possible after fix 1055.
You can merge this pull request
20 matches
Mail list logo
