Stephen,
I think the recent process of releasing the core makes it clear that weekly
official releases is not a viable concept. In the course of a week, 4 of the 25
PMC members voted and we haven't had a release in 6 months. Highly unlikely
we'll get a better turnout more frequently. I don't
Here are my thoughts on the discussions.
If we can get a tool chain working in Jenkins that build maven-core
and runs the ITs in an automated and reliable way - that's great. The
gold star in that should be the bare minimum required to do a release.
I see it as a stamp of approval that the
a release of that line.
That is the context in which I am suggesting that we could move to faster
releases...
Now there is a big *if* that I ack was my implicit unstated understanding
when I started the Towards faster releases thread... namely that:
A Patch/Incremental version is backwards
Well I guess we disagree as to how to get towards getting fixes to users
faster. My personal belief is that it is better to set out the goal and
find'n'fix the problems on the way to that goal rather than say there are
too many problems for now that we can't get to that goal.
I think weekly
On 20 February 2014 21:22, Dennis Lundberg dennisl.apa...@gmail.com wrote:
Here are my thoughts on the discussions.
If we can get a tool chain working in Jenkins that build maven-core
and runs the ITs in an automated and reliable way - that's great. The
gold star in that should be the bare
consider cutting a release of that line.
That is the context in which I am suggesting that we could move to faster
releases...
Now there is a big *if* that I ack was my implicit unstated understanding
when I started the Towards faster releases thread... namely that:
A Patch/Incremental
*if* that I ack was my implicit unstated understanding
when I started the Towards faster releases thread... namely that:
A Patch/Incremental version is backwards compatible bug fixes only. No
additional functionality. Additional functionality goes in a new minor
version.
I think
-3559 committed on the 3.2.x release line... then we should
consider cutting a release of that line.
That is the context in which I am suggesting that we could move to faster
releases...
Now there is a big *if* that I ack was my implicit unstated understanding
when I started the Towards faster
On 18 February 2014 22:49, Fred Cooke fred.co...@gmail.com wrote:
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?
It will
You missed the point. No-change commits include:
- Clean up white space
- Fix some comments in the code base
- POM tweaks that don't affect binary output
- Light genuine bonafide refactoring that causes no actual change in
behaviour at all
There is zero point to releasing these
On 19 February 2014 10:13, Fred Cooke fred.co...@gmail.com wrote:
You missed the point. No-change commits include:
- Clean up white space
- Fix some comments in the code base
- POM tweaks that don't affect binary output
- Light genuine bonafide refactoring that causes no actual
Sorry, still working on your first email in this thread which never
explicitly stated that, only implicitly, if your read the URL linked to,
AND happened to know what state 3.2.X was in. You did indeed point this out
at a later date. My mistake. But the first email set the tone, which is
hard to
On 19 February 2014 11:05, Fred Cooke fred.co...@gmail.com wrote:
Sorry, still working on your first email in this thread which never
explicitly stated that, only implicitly, if your read the URL linked to,
AND happened to know what state 3.2.X was in.
No worries
You did indeed point this
unstated understanding
when I started the Towards faster releases thread... namely that:
A Patch/Incremental version is backwards compatible bug fixes only.
No
additional functionality. Additional functionality goes in a new minor
version.
I think the resistance to my suggestion from
A bit of a recap:
Let's say that our goal as a group was to be very responsive to user's
bug reports.
So, we'd want to make fixes and releases, 'promptly', for some
definition of prompt.
But no one will install those releases if they are not confident that
they are, in fact, not going to have
I don't see any necessity to restrict patch releases to patches only -- as
long as any new functionality is a tiny enhancement and doesn't make
incompatibilities. Save medium/major structural changes for a new minor
version.
On Wed, Feb 19, 2014 at 7:37 AM, Benson Margulies
Agreed, if they small enhancements then I don't really want to release 4 things
issues in a patch release and then another 5. Generally I'm fine with small
enhancements, or small fixes going into patch releases, along with anything
marked @provisional as I'd rather have the experimental code in
Hello,
If you include new functionality this means that according to semver you
increase the second digit, which means conservative users will do this upgrade
step not so easy anymore (and therefore miss all future fixes).
I would rather include enhancements anyway but divert from strict
I need to remind people about the Apache rules here. Yes you can have
weekly builds. No you can't 'advertise them' in any way that is likely
to attract the attention of mere users as opposed to people engaged in
the development community. Please don't shoot me, I'm just the
messenger here.
On
So we have nightlies/weeklies and post to the dev list, that's fine.
On Feb 19, 2014, at 12:27 PM, Benson Margulies bimargul...@gmail.com wrote:
I need to remind people about the Apache rules here. Yes you can have
weekly builds. No you can't 'advertise them' in any way that is likely
to
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
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
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
37 matches
Mail list logo
