soon as we get a fix for either
> > MNG-5219 or MNG-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...
> >
On 20 February 2014 21:22, Dennis Lundberg 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 minimum required to d
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 mainte
x
>
> So my aim of faster releases becomes as soon as we get a fix for either
> MNG-5219 or MNG-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
>
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 quality
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 th
So we have nightlies/weeklies and post to the dev list, that's fine.
On Feb 19, 2014, at 12:27 PM, Benson Margulies 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 attract the attention o
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 Wed,
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 semve
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
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 wrote:
> A bit of a r
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 un
;s fix involves extending the API, so that would be 3.3.x
> > * MNG-5474 may introduce regressions if there is anyone depending on the
> > current behaviour, so that could be seen as 3.3.x
> >
> > So my aim of faster releases becomes as soon as we get a fix for either
> &g
On 19 February 2014 11:05, Fred Cooke 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 out
> at a later
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 sh
On 19 February 2014 10:13, Fred Cooke 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 change in
>
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 thi
On 18 February 2014 22:49, Fred Cooke 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 not work that way.
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... nam
.
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 compatible bug fixes only. No
additional functionality. Additional functionality goes in a new
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
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.
--
On Feb 18, 2014, at 4:23 PM, Stephen Connolly
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 workspace of a CI build that's
On Feb 18, 2014, at 4:32 PM, Benson Margulies 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 could disagree
> with
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 co
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 co
On 18 February 2014 23:58, Jason van Zyl 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 mo
On Feb 18, 2014, at 3:20 PM, Stephen Connolly
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 trying to
curate the issues for
On 18 February 2014 22:47, Jason van Zyl 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 wrote:
> >
> >>
> >> On Feb 18, 2014, at 11:47 AM, Stephen Connolly <
> >> stephen.alan.conno...@gmail.c
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
spur
On Feb 18, 2014, at 2:19 PM, Stephen Connolly
wrote:
> On Tuesday, 18 February 2014, Jason van Zyl wrote:
>
>>
>> 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
>>>
On Tuesday, 18 February 2014, Jason van Zyl wrote:
>
> 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 cutti
On Feb 18, 2014, at 11:47 AM, Stephen Connolly
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 are failing integration
> tes
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 swi
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
---
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
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 the
37 matches
Mail list logo
